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1.0  INTRODUCTION 


Tin's  document  is  the  final  report  concerning  TRW‘s  demonstration  of 
the  application  of  the  Software  Requirements  Engineering  Methodology  (SREM) 
to  an  existing  Government  Detailed  Functional  System  Requirements  (DFSR)t 
Document  under  Contract  DAHC26-80-C-0020 ,  and  is  submitted  in  accordance 
with  CDRL  A002.  It  was  prepared  for  the  Army  Institute  for  Research  and/ 
Management  Information  Computer  Science,  located  at  Georgia  Tech  — ^ 
University,  Atlanta,  Georgia.  It  documents  the  result  of  TRWs  application 
of  SREM  to  TM  38-171-2,  Detailed  Functional  System  Requirement  (DFSR)  - 
Volume  IV,  Standard  Army  Maintenance  System  (SAMS)  -  Retail  Level, 
Maintenance  Operations  Management  (MOM),  (SAMS-I)r^  The  objective  of  this 
effort  was  to  demonstrate  the  power  of  SREM  as  a  tool  to  verify  a  software 
requirement,  with  the  goal  of  determining  the  extent  to  which  it  was  a 
complete,  consistent,  and  unambiguous  document.  Specifically,  the  intent 
was  to  attain  an  understanding  of  what  SREM  is,  how  it  is  used,  and  what 
capability  it  possesses  for  isolating  discrepancies  in  an  existing  software 
specification.  In  addition,  this  effort  was  intended  to  provide  the  basis 
for  assessing  the  potential  of  SREM  for  inclusion  as  a  tool  in  the  current 
Army  ADP-system  development  life  cycle. 

This  report  is  published  in  two  volumes.  Volume  I  contains  the  basic 
report  text,  while  Volume  II  contains  the  appendices  that  accompany  this 
report. 
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1.1  SCOPE  AND  APPROACH  OF  THE  SREM  APPLICATION 

SREM  includes  a  seven-phase  effort,  which  is  shown  pictorially  in 
Figure  1-1.  However,  the  SREM  effort  under  this  contract  was  limited  to 
Phases  1  through  4.  The  efforts  in  the  omitted  phases  involve  the  determi¬ 
nation  of  YAL I DATI ON_PO I NTs  and  V AL I D AT I ON_P ATH s  for  PERFORMANCE_ 
REQUIREMENTS  plus  two  simulation  phases  for  dynamically  checking  the  soft¬ 
ware  requirements. 

The  assessment  of  the  adequacy  of  the  MOM  DFSR  specification  was 
accomplished  utilizing  the  following  tasks: 

•  Definition  of  interface  elements 

•  Definition  of  stored  information 

•  Definition  of  processing  logic 

•  Definition  of  traceability 

•  Evaluation  using  the  Requirements  Analysis  and  Data 
Extraction  ( RADX )  capability  resident  in  the  supporting 
software. 

Additional  tasks  accomplished  under  the  contract  included  a  description  of 
«  The  contents  and  application  of  SREM  and  its  components 

•  The  current  state  of  SREM  development 

•  The  applicability  of  the  current  SREM  approach  to 
Management  Information  Systems 

•  SREM  capability  versus  other  similar  techniques 

•  How  SREM  might  be  modified  to  improve  its  capability. 
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Figure  1-1  The  Seven  Phases  of  SREM  Engineering  Activity 


1.2  SUMMARY  OF  RESULTS 

The  power  of  the  use  of  SREM  to  discover  discrepancies  in  software 
specifications  was  confirmed  as  a  result  of  this  effort.  A  total  of  302 
Trouble  Reports  were  written  to  document  the  discrepancies  discovered  in 
the  logic  of  processing  outlined  in  Decision  Logic  Tables  (DLTs)  within  the 
MOM  DFSR,  and  in  their  data  consistency  when  compared  to  the  data  named  in 
Annexes  A,  B,  C  and  D.  Although  many  of  the  discrepancies  were  minor, 
there  were  several  significant  problems,  as  are  discussed  in  the  body  of 
the  report. 

Mo  concerted  attempt  was  made  to  determine  all  of  the  inconsistencies 
between  the  text  descriptions,  functional  flow  diagrams,  and  the  DLTs. 

These  internal  inconsistencies  were  quite  apparent,  and  a  few  have  been 
reported  via  Trouble  Reports.  However,  SREM  was  not  designed  to  harmonize 
these  kinds  of  problems.  Rather,  it  is  a  tool  to  investigate  the  logic  of 
the  processing  specified  in  the  context  of  the  inputs  received  and  the 
expected  outputs  produced  by  the  data  processor.  Accordingly,  the  SREM 
application  was  primarily  applied  to  the  most  detailed  available  informa¬ 
tion  concerning  processing  intent,  as  was  provided  by  the  DLTs. 

Although  there  are  some  enhancements  that  should  he  investigated  to 
aid  the  application  of  SREM  for  better  support  of  Management  Information 
Systems,  SREM  Is  clearly  applicable  to  software  applications  of  this  type, 
and  can  be  applied  in  its  current  state. 

In  addition  to  its  proven  capability  as  a  verification  tool  for  an 
existing  software  specification  at  the  DFSR  level,  SREM  can  produce  an  even 
greater  positive  impact  on  software  development  if  the  DFSR-level  specifi¬ 
cation  is  actually  developed  from  the  system  level  software  requirements 
(presumably  the  General  Functional  Systems  Requirement  (GFSR)).  When 
applied  at  that  stage  of  development,  the  proposed  approach  can  easily  be 
communicated  and  understood.  Because  of  the  improved  communication  between 
the  developer  and  the  user  early  in  the  development  cycle,  the  user  can 
judge  whether  the  proposed  decomposition  of  the  system  level  reauirements 
(to  the  software  requirements)  will  produce  what  is  actually  intended.  If 
not,  appropriate  correction  can  be  easily  implemented  well  before  such 
changes  become  prohibitively  expensive.  In  addition,  the  effort  by  the 
software  engineer  to  decompose  the  GFSR  level  requirements  to  the  DFSR 
level  using  SREM  will  highlight  areas  where  insufficient,  ambiguous,  or 


conflicting  information  exists.  Again,  by  raising  such  issues  early  in  the 
development  phase,  the  true  intent  of  the  user  can  be  determined  and  fac¬ 
tored  into  the  DFSR  very  early  in  the  development  cycle. 

A  comparison  of  SREM  to  the  capabilities  of  other  software  require- 
ments  techniques  was  accomplished.  SREM  was  shown  to  be  not  only  tech¬ 
nically  superior  to  the  others,  but  to  allow  lower  software  application 
life-cycle  costs  as  well. 
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1.3  OVERVIEW  OF  THIS  REPORT 


Section  2  of  this  report  provides  a  tutorial  description  of  SREM. 

This  includes  the  following  considerations: 

•  The  Requirements  Statement  Language  (RSL). 

•  The  automated  support  tools  incorporated  in  the 
Requirements  Engineering  and  Validation  System  (REVS) 
with  emphasis  on  the  Requirements  Analysis  and  Data 
Extraction  (RAOX)  function,  which  provides  the  capa¬ 
bility  to  test  the  adequacy  of  the  requirements  data 
base,  and  to  provide  documentation  of  its  content. 

•  The  application  methodology,  including  development  of 
Requirements  Nets  (R_NETs)  used  to  define  the  processing 
response  to  the  various  input  stimuli  and  to  provide  the 
ability  for  early  software  test  planning. 

•  Management  considerations. 

•  REVS  software  installation  information. 

Section  3  describes  the  basic  tasks  accomplished  under  this  contract 
and  their  results.  It  includes  a  discussion  of  our  approach  to  the  defini¬ 
tion  of  interface  elements,  stored  information,  processing  logic  ( R_NET s ) , 
and  traceability.  Further  discussion  is  provided  with  more  detail  on  RADX 
use  for  evaluation  of  the  requirements  data  base,  and  the  results  of  the 
RADX  evaluation  are  presented.  Finally,  a  discussion  of  the  statistics  of 
the  manloading  application  necessary  to  accomplish  the  SREM  tasks  is 
provided. 

Section  4  discusses  the  results  of  the  evaluation  of  the  MOM  DFSR. 

The  kinds  and  degree  of  deficiencies  found  and  documented  by  Trouble 
Reports  are  presented,  and  a  discussion  of  the  general  effects  of  the  DFSR 
deficiencies  are  summarized.  A  discussion  on  the  reoeneration  of  the  DFSR 
using  the  documentation  capability  of  RADX  is  also  provided. 

Section  5  compares  SREM  to  other  competing  software  reauirements 
engineering  tools,  to  include  relevant  similarities  and  differences.  This 
discussion  includes  the  important  matter  of  total  life  cycle  software  costs 
as  a  criteria  for  selecting  a  requirements  engineering  technique.  It  is 
shown  to  be  an  appropriate  way  to  assess  the  value  of  these  tools,  since 
more  than  just  their  initial  application  costs  should  be  considered. 

Section  6  completes  this  report  and  discusses  the  apol icabil ity  of 
SREM  to  Management  Information  Systems.  It  also  summarizes  a  few  limita- 


tions  experienced  with  SREM  in  the  verification  of  software  applications, 
such  as  the  MOM  DFSR.  Enhancement  of  RSL/REVS  to  ameliorate  these  limita¬ 
tions  is  discussed  as  a  means  to  provide  a  more  powerful  SREM  capability 
for  developing  and/or  analyzing  software  requirements  in  the  development  of 
management  information  systems.  All  of  these  sections  are  contained  in 
this  volume  (Volume  I)  of  the  report. 
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2.0  THE  TRW  SOFTWARE  REQUIREMENTS  ENGINEERING  METHODOLOGY 


The  Software  Requirements  Engineering  Methodology  (SREM),  developed 
for  scientific  systems,  embodies  four  years  of  concentrated  research  di¬ 
rected  toward  the  generation  of  better  software  requi rements.  As  most  of 
the  fundamental  concepts  are  directly  applicable  in  the  management  infor¬ 
mation  system  environment,  a  re-statement  of  the  original  SREM  objective 
and  an  overview  of  existing  capabilities  and  recent  developments  is 
appropriate. 
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2.1  PURPOSE  AND  BACKGROUND  OF  SREM 

In  the  Fall  of  1974,  the  Data  Processing  Directorate  of  the  U.S.  Army 
Ballistic  Missile  Defense  Advanced  Technology  Center  ( BMDATC )  initiated  a 
series  of  research  programs  directed  to  the  development  of  a  complete  and 
unified  approach  to  software  development.  These  programs  encompassed  the 
total  range  of  activities  from  development  of  system  specifications  through 
completion  and  testing  of  the  software  process  design.  Supporting  programs 
were  also  conducted  to  perform  basic  research  into  such  areas  as  software 
reliability,  static  and  dynamic  validation  techniaues,  and  adaptive  control 
and  learning. 

A  key  element  of  the  BMDATC  programs  was  the  Software  Requirements 
Engineering  Program  (SREP).  This  was  a  research  effort  concerned  with  a 
systematic  approach  to  the  development  of  complete  and  validated  software 
requirements  specifications.  As  shown  in  Figure  2-1,  errors  made  in  the 
requirements  phase  become  increasingly  more  expensive  to  locate  and  correct 
in  the  later  phases  of  development. 


Figure  2-1  The  Penalty  of  Requirements  Errors 


Ambiguity  and  lack  of  precision  in  the  requirements  statements  lead 
to  misinterpretation  (and  therefore  errors)  in  the  subsequent  development 
phases  and  add  further  to  cost  and  schedule  overruns.  Consistent  with 
alleviating  these  problems  with  current  requirements  specification  prac¬ 
tices,  the  overall  objectives  of  the  SREP  research  were  to: 

•  Ensure  a  well-defined  technique  for  decomposition  of 
system  requirements  into  structured  software 

requi rements . 

•  Provide  a  mechanism  for  enhanced  management  visibility 
into  the  requirements  development. 

•  Maintain  requirements  development  independent  of  the 
target  machine  and  the  eventual  software  design. 

•  Allow  for  easy  response  to  system  requirements  change. 

•  Provide  for  testable  and  easily  validated  software 
requirements. 


2.2  SREM  OVERVIEW 


To  meet  these  objectives,  the  Software  Requirements  Engineering 
Methodology  (SREM)  was  developed.  SREM  is  a  forma),  step-by-step  process 
for  defining  data  processing  requirements .  It  provides  a  means  to  eval¬ 
uate  system  requirements  and  enables  preparation  of  good  software  specifi¬ 
cations  prior  to  design  and  coding. 

SREM  is  designed  to  provide  certain  qualities  often  lacking  in  many 
software  requirements.  The  most  important  of  these  are: 

•  INTERNAL  CONSISTENCY,  which  is  difficult  to  attain  when 
applying  traditional  techniques  on  large  systems. 

•  EXPLICITNESS,  which  requires  unambiguous,  complete 
descriptions  of  what  is  to  be  done,  when,  and  with  what 
kind  of  data. 

t  TESTABILITY,  which  ensures  that  ALL  performance 
requirements  are  directly  testable. 

•  TRACEABILITY,  which  allows  easy  impact  assessment  of 
changes  to  system  requirements . 

The  basic  elements  of  SREM  are  the  methodology  of  application,  its  lan¬ 
guage,  and  the  automated  software  tools  to  support  the  application  effort. 
The  Requirements  Statement  Language  (RSL)  provides  the  user  with  the  abil¬ 
ity  to  define  software  requirements  in  a  form  which  assures  unambiguous 
communication  of  explicit,  testable  requi rements ,  and  combines  the  read¬ 
ability  of  English  with  the  rigor  of  a  computer-readable  language.  The 
Requirements  Engineering  and  Validation  System  (REVS)  provides  the  auto¬ 
mated  tools  for  translating,  storing,  analyzing,  simulating,  and  docu¬ 
menting  requirements  written  in  RSL.  Through  the  use  of  RSL  and  REVS,  the 
engineer  can  verify  the  completeness  and  consistency  of  a  software  specifi¬ 
cation  with  a  high  degree  of  confidence. 
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2.3  THE  NEW  PERSPECTIVE  OF  SREM 

This  methodology  is  an  integrated,  structured  approach  to  require¬ 
ments  engineering  activities.  SREM  begins  with  the  translation  and  decom¬ 
position  of  system  level  requi rements ,  or  with  the  verification  of  an 
existing  software  specification.  It  performs  analysis,  definition,  and 
validation  of  the  ADP  requirements;  and  ends  with  computer  supported  docu¬ 
mentation  of  the  completed  software  requirements.  It  represents  a  dif¬ 
ferent  approach  and  philosophy  for  software  requirements  engineering  in 
that  it  embodies  a  flow  orientation  which  eliminates  many  of  the  problems 
inherent  in  the  classical  functional  hierarchy. 

The  common  practice  of  organizing  software  requirements  into  a  hier¬ 
archy  of  functions,  subfunctions,  etc.,  while  superficially  appealing, 
leads  to  difficulties  in  both  the  expression  and  the  verification/vali¬ 
dation  of  the  requirements.  This  is  due,  in  part,  to  the  fact  that  such 
organization  does  not  fit  the  basic  input-process-output  nature  of  data 
processing,  and  in  part  to  the  fact  that  a  hierarchical  tree  of  arbitrarily 
defined  “functions"  does  not  have  a  sufficiently  rigorous  mathematical 
basis  to  allow  automated  analysis  for  the  completeness  and  consistency 
properties  of  the  resulting  specification.  To  avoid  these  difficulties, 

RSL  and  REVS  are  based  on  the  concept  of  processing  flow,  a  stimulus- 
response  approach.  Software  requirements  written  in  RSL  are  formulated  in 
terms  of  a  mathematical  network  (graph  model)  called  a  Requirements  Network 
(R-NET).  This  approach  provides  several  advantages: 

t  Describing  the  required  processing  in  terms  of  a  "logic 
diagram"  of  the  system  is  natural  to  most  engineers. 

•  The  mathematical  properties  of  an  R-NET  allow  automated 
analysis  for  consistency  and  completeness  through  the 
application  of  graph  theory. 

•  The  flow  orientation  of  an  R-NET  allows  automated 
generation  of  simulation  directly  from  the  stated 
requirements. 

Flows  through  a  system  are  specified  on  the  R-NETs,  which  consist  of 
nodes  which  specify  required  processing  operations  and  connecting  arcs. 

The  basic  nodes  are  INPUT_INTERFACEs,  OUTPUT_INTERFACEs ,  and  required 
processing  activities  called  ALPHAS.  Through  the  use  of  these  basic  nodes, 
the  required  paths  of  processing  can  be  specified.  For  example,  if  data  is 
to  be  input  to  the  data  processor  through  an  INPUT  INTERFACE  called  A, 
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processed  by  a  processing  step  (ALPHA)  called  B,  then  processed  by  an  ALPHA 
called  C,  and  the  result  output  through  an  OUTPUT_INTERFACE  called  D,  then 
the  required  processing  path  can  be  specified  by  listing  the  sequence  of 
operations : 

INPUTJNTERFACE:  A 
ALPHA:  B 
ALPHA:  C 

OUTPUT_INTERFACE:  D 

This  simple  R  MET  is  illustrated  graphically  in  Figure  2-2. 


Figure  2-2  An  Elementary  R_MET 

In  the  above  example,  the  sequence  ALPHA  3-ALPHA  C  means  that  those 
processing  steps  must  be  performed  in  the  indicated  sequence.  In  many 
cases,  the  actual  order  of  processing  is  immaterial.  This  can  be  specified 
through  the  use  of  an  AND  node  as  shown  in  Figure  2-3.  This  structure 
means  that  both  B  and  C  must  be  performed  after  receipt  of  data  through  A 
and  before  the  result  is  output  through  D,  but  B  and  C  are  sequentially 
independent  and  may  be  performed  in  any  order  (or  in  parallel). 

Most  systems  also  require  the  specification  of  decision  (control  1 
points.  Thus,  in  the  above  example,  if  3  is  to  be  performed  under  some 
circumstances  (depending  on  the  value  of  the  input  data,  for  example)  and  C 
is  to  be  performed  otherwise,  a  decision  point  and  its  attendant  decision 
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Figure  2-3  Use  of  AND  Nodes  in  R_NETs 

criterion  must  be  specified.  This  is  specified  in  an  R_NET  through  the  use 
of  an  OR  node  as  illustrated  in  Figure  2-4.  The  second  OR  node  following  B 
and  C  means  that  the  processing  is  to  continue  (i.e.,  output  the  results 
through  D)  if  processing  on  either  input  branch  has  been  completed. 

Through  the  use  of  the  INPUT  JNTERF  ACE,  ALPHA,  and  OUTPUT_INTERFACE , 
plus  the  AND  and  OR  nodes,  complete,  complex  processing  reauirements  can  be 
readily  specified.  Other  nodes  are  provided  to  specify  selection  of  data 
to  be  processed  (SELECT,  FOR  EACH),  to  designate  "test  points"  for  spec¬ 
ifying  performance  requirements  (VALIDATION  POINTs),  to  orovide  internal 
controls  ( EVENT s ) ,  and  to  summarize  detailed,  subordinate  processing  •Hows 
(SUBNETS) . 

The  Stimulus-Response  approach,  as  discussed  above,  for  the  analysis 
and  definition  of  software  specifications  has  become  the  cornerstone  of  the 
SREM  approach,  and  provides  a  new  perspective  for  (as  well  as  a  concise 
means  of)  describing  software  requirements. 
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2.4  RANGE  OF  SREM  ACTIVITIES 


The  starting  point  of  SREM  in  the  development  of  a  software  reauire- 
ment  from  the  system  level  is  the  point  in  systems  engineering  where  the 
system  requirements  analysis  has  identified  the  functions  and  the  stress 
points  of  the  specified  system;  the  interfaces  between  the  subsystems  (at 
least  on  the  functional  level);  top-level  system  functions  and  operating 
rules  (when  and  in  what  order  functions  are  to  be  performed);  and  top  level 
system  functions  have  been  allocated  to  the  data  processor.  In  the  case  of 
a  verification  effort,  it  begins  with  the  determination  to  investigate  the 
adequacy  of  an  existing  specification. 

For  both  of  the  above  cases,  SREM  is  considered  completed  when  the 
point  is  reached  where  primarily  software  development  expertise  is  required 
to  continue,  the  interfaces  have  been  defined  at  the  element  level,  all 
processing  steps  have  been  identified  with  appropriate  OP  requirements 
levied,  all  actions  of  the  DP  in  response  to  a  stimulus  are  determined  in 
terms  of  sequences  of  processing  steps,  and  the  processing  necessary  to 
generate  all  required  DP  output  interface  messages  has  been  specified.  The 
basic  difference  for  a  verification  effort  is  that  deficiencies  in  the 
existing  specification  will  have  been  documented  and  reported  to  the  extent 
that  the  above  characteristics  are  not  present. 


2.5  SREM  DEVELOPMENT  CONSIDERATIONS 

The  first  step  in  defining  the  Software  Requirements  Engineering 
Methodology  was  to  determine  the  properties  reauired  of  a  specification  and 
of  the  individual  requirements  of  which  it  is  composed.  The  initial  con¬ 
siderations  were  that: 

•  A  specification  is  the  set  of  all  requirements  which 
must  be  satisfied,  and  the  identification  of  the  subsets 
which  must  be  met  concurrently . 

§  A  specification  is  neither  realizable  nor  legally 
binding  unless  it  is  consistent  with  both  the  laws  of 
logic  and  the  laws  of  nature. 

•  A  specification  defines  the  properties  required  of  a 
product,  such  that  any  delivery  satisfying  the 
specification  satisfies  the  objectives  of  the  specifier. 

Taken  together,  the  above  considerations  lead  to  a  set  of  properties 
which  a  specification  must  have,  from  a  technical  point  of  view.  They  are: 

•  Internal  consistency. 

•  Consistency  with  the  physical  universe. 

•  Freedom  from  ambiguity. 

Economic  and  management  considerations  lead  to  the  following  set  of 
properties  which  a  good  specification  must  exhibit: 

•  Clarity. 

•  Minimality. 

•  Predictability  of  specification  development. 

•  Controllability  of  software  development. 

Since  freedom  from  ambiguity  was  mandatory,  a  machine- readable  state¬ 
ment  of  software  requirements  was  defined.  By  employing  an  unambiguous 
language,  and  by  translating  and  analyzing  it  with  a  program  intolerant  of 
ambiguity,  a  precise  statement  of  requirements  was  ensured. 

To  provide  an  internally  consistent  specification,  analyses  of  the 
requirements  statements  are  performed  by  the  REVS  software.  These  analyses 
include  semantic  and  syntactic  decomposition  of  the  individual  statements, 
and  analysis  of  the  composite  flow  of  data  and  processing.  SuDPort  of 
consistency  with  the  physical  universe  is  accomplished  by  converting  the 
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specification  unambiguously  into  a  simulation  which  can  be  executed  against 
a  model  of  the  real  world. 

Recently,  the  Government  has  required  that  tactical  software  be 
developed  in  accordance  with  DoD  Directive  5000.29.  One  key  aspect  of  this 
requirement  is  that  any  software  specification  must  be  validated  before 
being  imposed.  With  the  collection  of  tools  and  the  methodology  for  their 
use,  SREM  provides  a  means  for  this  validation  through  static  and  dynamic 
analysis  at  the  requirements  level. 

Finally,  to  support  control  of  both  the  specification  process  and 
software  development,  a  means  of  selective  documentation  and  analysis  of 
the  specification  is  provided.  The  integration  of  these  tools  with  a  sound 
and  methodical  engineering  and  management  approach  provides  predictability 
in  the  specification  process.  Further,  it  aids  in  avoiding  over- 
speci fi cation. 

SREM  was  developed  to  ensure  that  software  specifications  express  the 
real  needs  of  the  user.  Although  it  was  developed  explicitly  for  high 
technology  weapon  systems  problems,  it  is  grounded  on  fundamental  concepts 
relevant  to  all  types  of  data  processing.. 
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2.6  PRINCIPAL  COMPONENTS  OF  SREM 

The  three  components  of  SREM  are  the  Requirements  Statement  Language 
(RSL),  the  Requirements  Engineering  and  Validation  System  (REVS),  and  the 
application  methodology,  itself.  These  components  are  described  in  this 
secti on . 

2.6.1  The  Requirements  Statement  Language  (RSL) 

The  Requirements  Statement  Language  is  a  user-oriented  mechanism  for 
specifying  requirements.  It  is  oriented  heavily  toward  colloquial  English, 
and  uses  nouns  for  elements  and  attributes,  and  transitive  verbs  for  rela¬ 
tionships.  A  complementary  relationship  uses  the  passive  form  of  the  verb. 
Both  syntax  and  semantics  echo  English  usage,  so  that  many  simple  RSL 
sentences  may  be  read  as  English  with  the  same  meaning.  However,  the 
precision  of  RSL  enforced  through  machine  translation,  is  not  typical  of 
colloquial  speech.  As  a  result,  most  complex  RSL  sentences  are  a  somewhat 
stylized  form  of  English. 

The  basic  structure  of  RSL  is  very  simple  and  is  based  on  four  primi¬ 
tive  language  concepts:  elements,  attributes,  relationships,  and 
structures . 

El ements 

Elements  in  RSL  correspond  roughly  to  nouns  in  English.  They  are 
those  objects  and  ideas  which  the  requirements  analyst  uses  as  building 
blocks  for  his  description  of  the  system  requirements.  Each  element  has  a 
unique  name  and  belongs  to  one  of  a  number  of  classes  called  element  types. 
Some  examples  of  standard  element  types  in  RSL  are  ALPHA  (the  class  of 
functional  processing  steps),  DATA  (the  class  of  conceptual  pieces  of  data 
necessary  in  the  system),  and  R_NET  (the  class  of  processing  flow 
speci fi cations) . 

Attributes 

Attributes  are  modifiers  of  elements,  somewhat  in  the  manner  of 
adjectives  in  English,  and  they  formalize  important  properties  of  the 
elements.  Each  attribute  has  associated  with  it  a  set  of  values  which  may 
be  mnemonic  names,  numbers,  or  text  strings.  Each  particular  element  may 
have  only  one  of  these  values  for  any  attribute.  An  example  of  an  attri¬ 
bute  is  INITIAL  VALUE,  which  is  applicable  to  elements  of  type  DATA.  It 
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has  values  which  specify  what  the  INITIALJ/ALUE  of  the  data  item  must  be  in 
the  implemented  software  and  for  simulations. 

Relationships 

The  relationship  (or  relation)  in  RSL  may  be  compared  with  an  English 
verb.  More  properly,  it  corresponds  to  the  mathematical  definition  of  a 
binary  relation;  that  is,  a  statement  of  an  association  of  some  type 
between  two  elements.  The  RSL  relationship  is  not  symmetric;  it  has  a 
subject  element  and  an  object  element  which  are  distinct.  However,  there 
exists  a  complementary  relationship  for  each  specified  relationship  which 
is  the  converse  of  that  specified  relationship.  ALPHA  INPUTS  DATA  is  one 
of  the  relationships  in  RSL;  the  complementary  relationship  states  that 
OATA  is  INPUT  TO  an  ALPHA. 

Structures 

The  final  RSL  primitive  is  the  structure,  the  RSL  representation  of 
the  flow  graph.  Two  distinct  types  of  structures  have  been  identified. 

The  first  is  the  R_NET  (or  SUBNET)  structure.  As  previously  described,  it 
identifies  the  flow  through  the  functional  processing  steps  (ALPHAs)  and  is 
used  to  specify  the  system  response  to  various  stimuli.  The  second  struc¬ 
ture  type  is  the  VALIDATION_PATH,  which  is  used  to  specify  performance  of 
the  system. 

The  goal  of  stabilizing  requirements  in  a  natural  fashion  using  the 
stimulus-response  approach,  yet  being  rigorous  enough  for  machine  interpre¬ 
tation,  was  achieved  primarily  by  orienting  the  design  around  the  specifi¬ 
cation  of  flow  graphs.  Expression  of  structures  in  RSL  is  accomolished  by 
mapping  the  two-dimensional  graph  onto  a  one-dimensional  stream  suitable 
for  computer  input. 

The  RSL  structures  are  based  on  an  extension  to  the  basic  theory  of 
graph  models  of  computation  developed  at  UCLA  to  describe  the  intended 
operation  of  software.  -Many  of  the  rules  for  constructing  the  RSL  struc¬ 
tures  are  fixed  in  order  to  enforce  discipline,  to  preclude  the  user  from 
forming  flow  patterns,  and  to  ensure  that  each  R_MET  has  a  valid  logical 
basis.  Figure  2-5  shows  the  currently  allowable  nodes  that  may  be  incor¬ 
porated  into  a  legal  network,  and  their  eauivalent  RSL  description. 

Through  the  use  of  these  four  primitive  language  concepts,  a  basic 
requirements  language  is  provided  which  includes  concepts  for  specifying 
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processing  flows,  data  processing  actions,  and  timing  and  accuracy  require 
ments.  In  addition,  informative  and  descriptive  material  and  management- 
support  information  may  be  specified.  Using  these  primitives,  a 
nucleus  of  concepts  has  been  defined  which,  to  date,  has  proven  sufficient 
in  scientific  applications.  Concepts  supported  by  the  current  scientific 
version  of  the  language  are  summarized  in  Table  2.1. 


Table  2.1  Current  Nucleus  of  Defined  RSL  Elements,  Relationships  and 
Attributes 


ELEMENT  TYPES 

REUTIONSHIPS 

ATTRIBUTES 

ALPHA 

ASSOCIATES 

ALTERNATIVES 

OATA 

COMPOSES 

ARTIFICIALITY 

(DECISION 

CONNECTS 

3ETA 

ENTITY  CUSS 

CONSTRAINS 

CHOICE 

ENTITY  TYPE 

CONTAINS 

COMPLETENESS 

EVENT 

CREATES 

DESCRIPTION 

FILE 

OEUYS 

ENTERED  BY 

INPUT  INTERFACE- 

DESTROYS 

GAMMA 

MESSAGE 

DOCUMENTS 

INITIAL  VALUE 

ORIGINATING  REQUIREMENT 

ENA8LES 

10CALITT 

OUTPUT  INTERFACE 

EQUATES 

MAXIMUM  TIME 

PERFORMANCE  REQUIREMENT 

FORMS 

MAXIMUM  VALUE 

R  NET 

IMPLEMENTS 

minimumTime 

SffURCE 

INCLUDES 

MINIMUM  VALUE 

SUBNET 

INCORPORATES 

PROBLEM 

SUBSYSTEM 

INPUTS 

RANGE 

SYNONYM 

MAKES 

RESOLUTION 

UNSTRUCTURED  REQUIREMENT 

OROERS 

TEST 

VALIDATION  PATH 

OUTPUTS 

TYPE 

VALIDATION  POINT 

PASSES 

UNITS 

VERSION 

RECORDS 

SETS 

TRACES 

USE 

RSL  is  an  extensible  language  in  that  the  primitives  described  above, 
which  are  initially  built  in,  can  be  used  to  define  additional  complex 
language  concepts.  This  extension  capability  of  the  language  was  exercised 
throughout  the  application  of  SREM  to  the  MOM  DFSR,  and  the  extended  con¬ 
cepts  are  shown  in  Table  2.2. 

2.6.2  The  Requirements  Engineering  and  Validation  System  (REVS) 

The  Requirements  Engineering  and  Validation  System  (REVS)  is  designed 
to  allow  the  requirements  engineer  to  state  and  modify  requirements  infor¬ 
mation  over  a  period  of  time  as  the  requirements  are  developed.  The  RSL 
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Table  2.2  MOM  DSARC  Extended  RSI  Elements,  Relationships,  and  Attributes 


ELEMENT  TYPES 

RELATIONSHIPS 

ATTRIBUTES 

DATAJELEMENT 

LOGCJDEN 

MOM_FUNCTION 

PREPARATIONJATE 

RELATIVE_?OSN 

R£VIEW_QATE 

AS_0F 

C0DED_AS 

LOCATEDJN 

SUPPORTS 

USES 

CARO_FIRST  COLUMN 

CARO_LAST_CCL  UMN 

DEFINITION 

FIELD  J-ENGTH 

FIELQJYPE 

FREQUENCY_OF_US£ 

SROWTHJATE 

normal_access_<ey 

NRJCHARJERJECORD 

NR_CURRENT_RECOROS_?ER_.- 1 LE 

NR_PR0JECTED_R£C0R0S_PER_FTL£ 

?ROPOS£D_FILE_ORGN 

?R0P0SED_MEDIA 

PURGEJWTE 

REQUIREDJTEM 

RETENTION_PE3IOD 

SE  OJRITYJCLASS I FI CATI ON 

statements  that  an  engineer  inputs  to  REVS  are  analyzed,  and  a  repre¬ 
sentation  of  the  information  is  put  into  a  centralized  requirements  data 
base,  called  the  Abstract  System  Semantic  Model  (ASSM).  It  bears  this  name 
because  it  maintains  information  about  the  required  data  processing  system 
(RSL  semantics)  in  an  abstract,  relational  model.  Once  entered  into  the 
ASSM,  the  requirements  are  available  for  subsequent  refinement,  extraction, 
and  analysis  by  the  REVS  software. 

From  a  user  point  of  view,  there  are  five  major  functional  capabil¬ 
ities  which  REVS  provides. 

e  Processing  of  RSL. 

t  Interactive  generation  of  Requirements  Networks 
(R_NETs). 

•  Analysis  of  requirements  and  their  listing  in  RSL  and/or 
in  specially  formatted  reports,  using  the  Reauirements 
Analysis  and  Data  Extraction  (RADX)  capability. 

•  Generation  and  execution  of  functional  and  analytic 
simulators  from  functional  reaui rements ,  models,  or 
algorithms,  and  the  generation  and  execution  of 
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simulation  post-processors  from  analytic  performance 
requirements. 

•  Processing  of  extensions  to  RSL. 

REVS  and  RSL  allow  the  engineer  to  enter  requirements  into  the  re¬ 
quirements  data  base  as  they  are  developed,  with  REVS  checking  for  consis¬ 
tency  and  completeness  as  new  data  is  entered.  Although  the  REVS  capabil¬ 
ities  may  be  applied  in  any  order,  generally,  the  user  will  initially  build 
the  requirements  data  base,  and  then  reouest  various  Requirements  Analysis 
and  Oata  Extraction  { RADX )  static  analyses  to  be  performed.  Mew  entries 
will  be  made  and  additional  RADX  static  analysis  repeated  until  the 
requirements  have  been  sufficiently  developed  for  a  simulation  to  be  mean¬ 
ingful  and  useful.  At  that  time,  a. simulator  and  post-processor  may  be 
generated.  Once  generated,  it  may  then  be  executed  numerous  times  and  the 
data  recorded  and  analyzed.  Based  on  the  results,  this  seauence  may  be 
repeated,  starting  with  the  modification  of  the  existing  requirements  or 
the  addition  of  new  ones.  The  sequence  will  also  be  repeated  as  system 
requirements  change,  or  when  new  requirements  are  imposed.  When  the  user 
is  satisfied  that  the  retirements  are  correct,  based  upon  the  results  of 
static  and  dynamic  analysis,  REVS  will  document  the  requirements  in  a  form 
usable  in  a  software  requirements  specification. 

Each  of  the  major  capabilities  identified  above  is  allocated  to  a 
different  functional  component  of  REVS.  The  capabilities  of  these  func¬ 
tions  are  described  briefly  below. 

2. 6. 2.1  Processing  of  RSL 

The  analysis  of  RSL  statements  and  the  establishment  of  entries  in 
the  requirements  data  base  corresponding  to  the  meaning  of  the  statements 
is  performed  by  the  RSL  translation  function  of  REVS.  The  translation 
function  also  processes  the  modifications  and  deletions  from  the  data  base 
commanded  by  RSL  statements  specifying  changes  to  already-existing  entries 
in  the  data  base.  For  all  types  of  inout  processing,  the  RSL  translation 
function  references  the  data  base  to  do  simple  consistency  checks  on  the 
input.  This  prevents  disastrous  errors  such  as  the  introduction  of  an 
element  with  the  same  name  as  a  oreviously-existing  element,  or  an  instance 
of  a  relationship  which  is  tied  to  an  illegal  type  of  element.  Besides 
providing  a  measure  of  protection  for  the  data  base,  this  type  of  checking 


catches  some  of  the  simple  types  of  inconsistencies  that  are  often  found  in 
requirements  specifications  at  an  early  state,  without  restricting  the 
order  in  which  the  user  adds  to,  or  alters,  the  data  base. 

2. 6. 2. 2  Interactive  Generation  of  R-Nets 

Graphics  capabilities  to  interactively  input,  modify,  or  display 
R_NET,  SUBNET,  and  VALIDATI0N_PATH  structures  are  provided  through  the  REVS 
Interactive  R_N£T  Generation  (RNETGEN)  function.  RNETGEN  permits  entry  of 
structures  and  referenced  elements  in  a  manner  parallel  to  the  RSL  trans¬ 
lator,  and  thus  provides  an  alternative  to  the  RSL  translator  for  the 
specification  of  the  flow  portion  of  the  requirements.  Using  this  function, 
the  user  may  develop  (either  automatically  or  under  direct  user  control)  a 
graphical  representation  of  a  structure  previously  entered  in  RSL.  The 
user  may  work  with  either  the  graphical  or  RSL  language  representation  of  a 
structure;  they  are  completely  interchangeable. 

The  Interactive  R-NET  Generation  facility  contains  full  editing 
capabilities.  The  user  may  input  a  new  structure,  or  he  may  modify  one 
previously  entered.  When  satisfied  with  the  newly  generated  R_NET,  the 
user  may  cause  it  to  be  stored,  at  which  point  it  is  automatical ly  trans¬ 
lated  into  an  RSL  representation  and  stored  in  the  data  base.  At  the 
conclusion  of  the  editing  session  on  an  existing  structure,  the  user  may 
elect  to  replace  the  old  structure  with  the  modified  one.  The  editing 
functions  provide  means  to  position,  connect,  and  delete  nodes,  to  move 
them,  to  disconnect  them  from  other  nodes,  and  to  enter  or  change  their 
associated  names  and  commentary.  The  size  of  a  structure  is  not  limited  by 
the  screen  size  since  zoom-in,  zoom-out,  and  scroll  functions  are  provided. 

2. 6. 2. 3  Analysis  and  Output  of  Requirements 

The  RADX  function  provides  both  static  flow  analysis  capabilities  and 
the  capabilities  of  a  generalized  extractor  system  for  checking  the  com¬ 
pleteness  and  consistency  of  the  requirements  SDeci fi cation  and  for  the 
development  of  requirements  documentation.  The  static  flow  analysis  deals 
with  data  flow  through  the  R_NETs.  The  analysis  uses  the  R_MET  structure 
(in  much  the  same  manner  that  programming  language  data  flow  analyzers  use 
the  control  flow  of  a  program)  to  detect  deficiencies  in  the  flow  of  pro¬ 
cessing  and  data  manipulation  stated  in  the  requirements.  The  generalized 


extractor  system  allows  the  user  to  perform  additional  analysis  and  to 
extract  information  from  the  data  base.  The  user  can  subset  the  elements 
in  the  data  base  based  on  some  condition  (or  combination  of  conditions), 
and  display  the  elements  of  the  subset  with  any  related  information  he 
sel ects . 

Information  to  be  retrieved  is  identified  in  terms  of  RSL  concepts. 
For  example,  if  the  user  wants  a  report  listing  all  DATA  elements  which  are 
not  INPUT  to  any  ALPHA  (processing  step),  he  enters  the  following  commands: 

SET  A  =  OATA  THAT  IS  NOT  INPUT. 

LIST  A. 

By  combining  sets  in  various  ways,  he  can  detect  the  absence  or  presence  of 
data,  trace  references  on  the  structures,  and  analyze  inter-relationships 
established  in  the  data  base.  In  analyzing  user  requests  and  extracting 
information  from  the  data  base,  the  extractor  system  uses  the  definition  of 
the  language  concepts,  which  are  also  contained  in  the  data  base.  Thus,  as 
RSL  is  extended,  the  extensions  and  their  use  in  the  reauirements  are 
available  for  extraction.  Because  of  the  importance  of  the  use  of  RADX  in 
the  evaluation  of  the  requirements  data  base  and  in  the  regeneration  of 
requirements  in  this  effort,  a  more  detailed  description  of  RADX  is  Dro- 
vided  in  Paragraph  3.7,  preceding  the  description  of  our  RADX  evaluation 
effort. 

2. 6. 2. 4  Generation  and  Execution  of  Simulators  and  Post-Processors 

The  automatic  Simulation  Generation  (SIMGEN)  function  in  REVS  takes 
the  data  base  representation  of  the  requirements  of  a  data  processing 
system  and  generates  from  the  discrete  event  simulators  of  the  system. 

These  simulators  are  driven  by  externally  generated  stimuli.  The  baseline 
system  generates  simulators  to  be  driven  by  a  System  Environment  and  Threat 
Simulation  (SETS)  type  of  driver  program  which  models  the  system  environ¬ 
ment,  (and  the  threat,  where  appropriate)  and  the  components  of  the  system 
external  to  the  data  processing  system. 

Two  distinct  types  of  simulators  may  be  aenerated  by  REVS.  The  first 
uses  functional  models  of  the  processing  steps  and  may  emoloy  simplifi¬ 
cations  to  simulate  the  required  orocessing.  This  type  of  simulation 
serves  as  a  means  to  validate  the  overall  reauired  flow  of  processing 
against  higher  level  system  requirements.  The  other  type  of  simulator  uses 
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analytic  models.  These  are  models  that  use  algorithms  similar  to  those 
which  will  appear  in  the  software  to  perform  complex  computations.  This 
type  of  simulation  may  be  used  to  define  a  set  of  algorithms  which  have  the 
desired  accuracy  and  stability.  Although  real-time  feasibility  of  a  system 
cannot  be  established  using  this  algorithm  set,  the  simulation  does  provide 
proof  of  an  analytic  solution  to  the  problem.  Both  types  of  simulations 
are  used  to  check  dynamic  system  interactions. 

The  SIMGEN  function  transforms  the  data  base  representation  of  the 
requirements  into  simulation  code  in  the  programming  language  PASCAL.  The 
flow  structure  of  each  R_NET  is  used  to  develop  a  PASCAL  procedure  whose 
control  flow  implements  that  of  the  R_NET  structure.  Each  processing  step 
(ALPHA)  on  the  R_NET  becomes  a  call  to  a  procedure  consisting  of  the  model 
or  algorithm  for  that  ALPHA.  These  model s  (or  algorithms)  for  the  ALPHA 
must  have  previously  been  written  in  PASCAL.  The  data  definitions  and 
structure  for  the  simulation  are  synthesized  from  the  reauirements  data 
element  and  their  relationships  and  attributes  in  the  data  base. 

By  automatically  generating  simulators  from  the  data  base  in  this 
manner,  the  simulations  are  insured  to  match  and  trace  to  the  requi rements . 
Since  all  changes  are  made  to  the  requirements  statements  themselves,  new 
simulators  can  be  readily  generated  as  requirements  change  and  are  auto¬ 
matically  reflected  in  the  next  generation  of  the  simulator. 

For  analytic  simulations,  SIMGEN  also  generates  simulation  post¬ 
processors  based  on  the  statement  of  performance  reauirements  in  the  data 
base.  Data  collected  from  an  analytic  simulation  can  be  evaluated  using 
the  corresponding  post-processor  to  test  that  the  set  of  algorithms  met  the 
required  accuracies. 

Both  REVS  generated  simulators  and  post-processors  are  accessed  for 
execution  through  the  Simulation  Execution  (SIMXQT)  function  for  simu¬ 
lators,  and  the  Simulation  Data  Analysis  (SIMDA)  function  for  simulation 
post-processors. 

2. 6. 2. 5  Processing  Extensions  to  RSL 

As  mentioned  earlier,  the  data  base  contains  the  RSL  concepts  used  to 
express  requi rements,  as  well  as  the  reauirements  themseTves.  Extensions 
and  modifications  to  the  concepts  are  processed  by  the  RSL  Extension 
(RSLXTND)  function  of  REVS.  The  RSLXTND  function  is  actually  performed  by 
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the  same  software  as  RSL  translation,  but  is  accessed  separately  to  control 

extensions  to  the  language  through  a  lock  mechanism  built  into  the 
software. 

2. 6. 2. 6  REVS  Organization 

The  above  discussion  has  identified  seven  functions  of  REVS:  RSL, 
RNETGEN,  RADX,  SIMGEN,  SIMXQT,  SIMDA,  and  RSLXTND.  As  shown  in  Figure  2-6, 
these  functions  are  under  the  control  of  a  higher  level  function,  the  REVS 
Executive.  The  Executive  presents  a  unified  interface  between  the  user  and 
the  different  REVS  functions. 

2.6.3  The  Application  Methodology 

Historically,  the  methods  for-  developing  a  software  specification 
have  been  as  numerous  as  the  developers  of  such  documents.  In  fact,  few 
cases  can  be  cited  in  which  any  formal  methodology  could  be  auoted.  Until 
the  specification  appeared  (often  after  thousands  of  man-years  of  effort), 
nothing  was  available  to  show  that  it  would  actually  be  generated.  In 
addition,  it  has  frequently  been  true  that  the  quality  of  the  specifica¬ 
tion,  even  with  respect  to  elementary  consistency  from  one  requirement  to 
another,  could  be  verified  only  very  late  in  software  development.  Since 
the  problems  were  discovered  only  when  the  cost  of  correction  was  prohibi¬ 
tive,  the  requirements  were  frequently  changed,  degrading  system  perfor¬ 
mance  in  order  to  have  a  "workable"  product. 

In  our  research  we  found  that  a  methodology  was  needed  to  guide  the 
software  development,  and  to  make  progress  visible  via  measurable  mile¬ 
stones.  As  shown  in  Figure  2-7,  SREM  starts  with  a  specification  which  can 
be  a  formal  specification,  a  conversation  with  the  intended  user,  or  a 
mental  image  of  the  system.  In  addition,  it  has  been  found  that  SREM  may 
be  applied  to  an  existing  software  specification  to  verify  its  adequacy,  as 
has  been  done  in  this  effort  on  the  MOMS  OFSR. 

The  first  step  is  to  identify  the  specific  functional  and  performance 
requi remehts  of  the  system,  and  to  record  them  in  the  reauirements  data 
base  as  ORIGINATING_REQUIREMENTs  (what  processing  is  to  be  done)  or 
PERFORMANCE_RECUIREMENTs  (how  well  must  the  processing  be  done;  accuracy, 
timing,  etc.).  As  the  rest  of  the  methodology  proceeds,  the  need  for  the 
various  elements  defined  and  recorded  in  the  data  base  (R_METs,  MESSAGEs, 
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2-6  REVS  Functional  Organization 


Figure  2-7  The  SREM  Methodology  Process 


etc.)  should  have  stemmed  from  these  ORIGINATINGJREQUIREMENTs ,  and 
PERFORMANC£_R£QUIR£M£NTs.  Consequently,  a  traceability  is  established 
between  pertinent  elements  and  the  requirement  for  them.  Additionally,  as 
ambiguous  areas  of  the  requirement  are  clarified,  or  as  new  guidance 
results,  this  fact  can  be  documented  in  the  data  base  as  a  DECISION,  and 
various  elements  of  the  data  base  may  then  properly  be  traced  to  these 
decisions.  With  the  requirements  documented,  actual  definition  of  the 
software  requirement  can  be  initiated  to  meet  the  requirements. 

Based  on  the  system  specification  or  software  specification,  all 
interfaces  of  the  data  processor  are  first  identified,  together  with  the 
MESSAGES  that  cross  these  interfaces  and  the  MESSAGE  contents.  Next,  DATA 

and  FILE  information  is  identified  that  defines  the  information  required  to 
be  maintained  about  items  of  interest  to  the  processing.  These  are  stored 
in  ENTITY_CLASSes  or  ENTITY_TYPEs.  R_NETs  are  then  develoDed  to  specify 
stimul us/ response  relationships  required  of  the  software  to  process  each  of 
the  input  messages.  We  are  now  at  Point  A  on  Figure  2-7.  During  this 
process,  specific  problems  in  the  system  specification  will  be  found  (such 
as  ambiguities  and  inconsistencies).  These  problems  are  corrected  by  an 
iterative  process  between  the  software  engineer  and  the  user  until  the 
specification  is  thought  to  be  complete. 

Next,  the  details  of  the  functional  requirements,  including  all  of 
the  input/output  data  relationships,  the  processing  steps,  the  attributes, 
maximum  values,  minimum  values,  and  the  allowed  data  ranges,  are  completed. 
RSL  is  used  to  input  these  requirements  into  the  data  base,  and  RADX  is 
executed  to  test  for  errors  in  consistency  and  completeness.  When  all  the 
information  has  been  input  and  all  the  errors  corrected,  the  result  is  a 
functional  specification  (Point  3),  or  in  the  case  of  a  verification  ef¬ 
fort,  a  verified  functional  specification. 

Before  the  functional  specification  can  be  finalized  a  simulation  of 
the  system  is  appropriate.  First,  simple  functional  models  are  developed 
for  each  of  the  processing  steps  and  put  through  the  simulation  generation 
function  to  establish  the  model  for  simulation.  Once  all  models  are  built, 
the  simulator  is  executed  to  verify  the  entire  process  (Point  C).  Again, 
we  emphasize  that  the  simulation  is  actually  accomplished  using  the  r'e- 
quirements  data  base  and  the  processing  logic  defined  in  the  R_METs.  rhe 
result  is  confidence  in  the  correctness  of  the  requirements  data  base  since 
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it  provides  checks  not  possible  from  static  analysis  alone.  For  example, 
the  simulation  can  address  whether  the  DATA  input  to  the  data  base  in  one 
R_NET  and  used  in  a  different  R_NET  is  actually  present  for  use  when  the 
using  R_NET  is  exercised  by  the  simulation. 

After  the  functional  requirement  specification  is  validated,  the 
PERFORMANCE_REQUIREMENTS  are  developed.  Such  PERFORMANCE_REQUIREMENTS 
usually  aren't  well  structured;  they  are  stated  in  system  terms  such  as 
"kill  probability 11  and  ''miss  distances”  for  which  the  software  shares  only 
partial  responsibility.  The  paths  of  the  defined  processing  must  be  mapped 
and  the  paths  which  are  being  CONSTRAINED  by  these  PERFORMANCE_REQUIREMENTS 
must  be  identified.  Trade  studies  at  this  level  will  be  performed  until 
the  right  performance  requirements  are  allocated  for  each  path.  When  all 
of  the  paths  are  identified,  the  timing  and  analytic  accuracy  requirements 
are  specified  for  each  of  the  paths,  and  all  of  this  information  is  input 
to  the  REVS  data  base.  Completion  of  these  steps  results  in  a  valid  soft¬ 
ware  specification  (Point  D). 

Before  attempting  to  build  expensive  real-time  code  it  may  be  neces¬ 
sary  to  verify  that  the  system  is  analytically  feasible.  To  do  this,  one 
more  simulation  step,  called  the  analytical  feasibility  demonstration, 

should  be  performed.  This  step  will  use  real  algorithms  instead  of  func¬ 
tional  models  for  the  processing  steps.  It  may  not  run  in  real-time,  but 
it  should  consist  of  real  algorithms  expected  to  be  used  in  the  software. 

It  should  be  driven  by  a  driver  with  enough  fidelity  to  represent  the  best 
understanding  of  the  environment  and  measurements  of  the  system  to  verify 
that  the  software  will  actually  provide  the  accuracies  reauired  (Point  E). 

The  methodology  developed  within  SREM  is  not  only  formal  (in  that  it 
provides  an  explicit  sequence  of  steps  leading  to  a  validated  specificat¬ 
ion)  but  it  is  also  manageable,  enumerating  multiple  phases  for  management 
review  and  analysis.  Since  it  works  from  the  highest  levels  of  software 
definition  (processing  and  data  flows)  to  the  most  detailed  (analytic 
models  and  data  content)  in  a  systematic  manner,  it  supports  early  detec¬ 
tion  of  high-level  anomalies.  A  key  feature  of  SREM  is  that  the  processing 
functions  and  data  communications  are  considered  in  parallel,  rather  than 
have  either  following  the  other.  As  a  result,  the  connectivity  of  the 
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system  is  always  complete,  and  it  becomes  possible  to  partition  the  re¬ 
quirements  effort  among  several  groups  early  in  the  process  without  risking 


2.7  SPECIFICATION  MANAGEMENT 

The  management  of  a  specification  developed  under  SREM  benefits  most 
from  the  conwon  source  in  the  data  base  of  all  the  representations  of  the 
software  requirements.  Thus,  the  simulation  of  the  specification  and  the 
documentation  of  its  requirements  will  be  consistent  at  all  times,  since 
both  have  a  single  source  of  data  for  their  generation  without  human  inter¬ 
vention.  In  addition  to  a  common  data  base,  the  methodology  itself  sup¬ 
ports  orderly  software  development  planning  and  management,  expedites 
review  and  analysis  of  the  effort,  assists  communication  of  the  details  of 
the  effort  between  participants,  provides  consistent  rapidly  attainable 
documentation,  simplifies  impact  analysis  of  requirement  changes,  and 
assures  early  test  planning  capability.  These  valuable  capabilities  for 
any  software  manager  are  briefly  illustrated  below. 

2.7.1  Management  Planning  and  Control 

Because  the  methodology  is  a  step-by-step  sequence  of  events  with 
recognizable  starting  and  ending  points,  it  can  be  annotated  with  mile¬ 
stones,  recorded  on  charts,  and  otherwise  controlled  with  the  management 
tools  of  the  last  several  decades  to  provide  predictabil ity  and  control . 
This  is  not  to  suggest  that  the  creativity  of  the  specification  process  can 
either  be  scheduled  or  by-passed;  it  is  still  needed.  However,  the  metho¬ 
dology  isolates  it  into  segments  with  high  visibility,  and  supports  manaoe- 
ment  cognizance  of  its  progress  and  impact. 

Work  may  be  easily  assigned  in  a  logical  fashion  because  of  the 
stimulus  response  approach  of  this  methodology.  Since  each  INPUT_INTERFACE 
identified  for  the  system  is  the  source  of  all  the  input  MESSAGES  (stimuli) 
passing  through  it,  a  division  of  responsibility  by  INPUT_INTERFACE  is 
appropriate.  Thus,  an  engineer  becomes  responsible  for  developing  the 
R_NET  for  that  interface  and  all  the  appropriate  related  information  for 
insertion  into  the  requirements  data  base.  Each  requirements  engineer 
generally  accomplishes  the  same  methodology  steps  with  his  assigned  effort 
which,  during  the  initial  phase,  are  as  illustrated  in  Figure  2-6.  The 
typical  Management  Milestones  are  also  shown  in  that  figure. 

It  is  not  necessary  for  one  step  to  be  completely  finished  in  all 
respects  before  the  next  can  be  undertaken.  In  most  cases,  the  interfaces 
and  MESSAGES  from  some  SUBSYSTEMS  may  be  defined  before  those  of  others;  in 
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Figure  2-8  Relationship  of  Methodology  Steps  in  Phase  1  of  SREM 


this  case,  work  could  be  initiated  on  the  R_NET  definition  while  interfaces 
are  being  defined  for  the  remainder  of  the  system.  The  parallel  aspects  of 
the  network  exemplify  the  modular  capability  for  parallel  R  MET 
development. 

To  be  useful  for  management  control,  it  must  be  possible  to  recognize 
when  each  milestone  is  completed.  As  will  be  shown,  determination  of  the 
status  of  these  and  other  milestones  can  be  attained  by  auerying  the  ASSM 
data  base  in  various  ways  using  the  RADX  system. 

2.7.2  Review  and  Analysis 

The  software  manager  who  is  using  SREM  has  a  ready  means  to  determine 
project  progress  (or  lack  thereof)  for  his  internal  review  and  analysis,  or 
to  meet  the  need  for  specific  information  to  support  reviews  by  higher 
level  management,  or  by  the  user.  This  is  accomplished  through  the  capa¬ 
bilities  of  RADX.  A  standard  set  of  RADX  tests  have  been  developed  to 
assure  that  the  data  base  will  produce  a  complete,  consistent,  unambiguous 
specification.  Figure  2-9  provides  an  example  of  a  few  of  these  pre¬ 
specified  queries. 

In  addition,  REVS  users  may  form  their  own  queries.  At  review  time, 
for  example,  the  manager  can  query  the  data  base  to  determine  the  status  of 
efforts  expected  to  have  been  accomplished  by  the  time  of  the  review.  This 
capability  eliminates  much  of  the  need  for  subjective  evaluation  of  pro¬ 
gress.  Here  is  a  sample  of  the  kinds  of  data  that  could  be  obtained: 

t  INPUT  INTERFACES  that  do  not  PASS  MESSAGES.  This  would 
indicate  that  MESSAGES  that  will  be  passed  by  this 
interface  have  not  yet  been  determined  and  entered  into 
the  data  base. 

•  R  NETs  that  are  not  ENABLED  by  an  existing  INPUT 
INTERFACE.  This  would  indicate  that  the  R_NET  for  that 
INPUT_INTERFACE  has  not  yet  been  defined  in  the  data 
base. 

•  MESSAGES  that  are  not  MADE  BY  DATA  or  FILE  information. 

These  are  messages  whose  contents  have  not  yet  been 
defi ned. 

These  are  only  a  few  of  the  considerable  list  of  queries  that  could  be  used 
to  determine  status.  Actually,  different  sets  of  aueries  would  be  aooro- 
priate  during  each  phase  of  the  SREM  process. 
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Figure  2-9  Partial  List  of  Prespecified  RADX  Tests 

The  output  from  each  query  (called  a  SET)  provides  a  number  which 
identifies  the  quantity  of  elements  in  the  data  base  that  satisfy  the 
specified  query,  and  a  listing  of  each  of  the  elements  in  the  SET.  For 
example,  in  the  third  sample  above,  after  indicating  the  Quantity  of 
MESSAGES  that  are  not  MADE  BY  DATA  or  FILES,  the  names  of  each  MESSAGE 
would  be  listed.  Because  of  the  formality  of  RSL,  and  the  specific  meanina 
of  its  components,  communication  is  facilitated  in  discussions  with 
engineers  on  problems  identified  through  RADX  extractions  such  as  these. 


2.7.3  Technical  Communication 

Of  all  of  the  capabilities  that  SREM  oossesses,  the  capability  to 
expedite  technical  comnunication  is  the  one  most  often  mentioned  by  users 
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as  an  unexpected  payoff.  The  R_NET  and  SUBNET  structures  are  the  primary 
reason  this  is  so.  These  structures  are  easy  to  understand  and  can  distill 
large  amounts  of  text  into  a  compact  flow  diagram.  The  clarity  of  this 
approach  is  illustrated  in  Figure  2-10  for  an  R_NET  describing  the  proces¬ 
sing  required  for  an  Aircraft  Engine  Monitoring  System.  In  this  system,  a 
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Figure  2-10  R_NET  for  the  Engine  Monitoring  System 

MESSAGE  is  periodically  received  containing  aircraft  engine  temoeratures 
and  pressures  and  is  to  be  processed  so  that  the  flight  engineer  is  warned 
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when  engine  conditions  are  out  of  limits.  In  addition,  the  engine  readings 
are  to  be  stored  to  provide  engine  history.  Although  the  reader  is  pro¬ 
bably  not  too  familiar  with  R_NET  structures,  it  is  not  very  difficult  to 
form  a  good  idea  of  what  is  supposed  to  happen  in  the  processing.  The  only 
concept  not  previously  discussed  is  the  circles  labeled  VI  through  V4. 

These  are  VALIDATION  POINTS  which  RECORDS  DATA  and  FILE  information  needed 
for  software  testing. 

Because  of  the  ability  the  R_NET  has  for  efficient  communication,  it 
is  superb  for  use  in  engineering  reviews,  coordination  between  engineers, 
and  discussions  between  managers  and  their  engineers.  In  addition,  and 
perhaps  for  the  first  time,  the  user  can  be  given  a  chance  to  understand¬ 
ably  review  the  perceived  software  requirements  (via  the  R_NETs),  with  the 
distinct  probability  that  he'll  be  able  to  identify  areas  where  his  inten¬ 
tions  were  not  properly  specified,  and  thus  provide  for  correction  before 
software  design  is  started. 

Another  glance  at  the  R_NET  in  Figure  2-10  will  provide  an  under¬ 
standing  of  the  ease  with  which  such  errors  can  be  identified.  Note  that 
at  the  OR  Mode  immediately  below  the  ALPHA  called  VALIDATE_MESSAGE,  one  of 
two  branches  is  followed,  depending  on  the  result  of  the  processing  in  this 
preceding  ALPHA.  If  the  result  produces  the  DATA  item  called  DATA  VALIDITY 
with  the  value  of  N0T_VALID,  processing  ends  for  that  MESSAGE.  An  astute 
user  would  quickly  perceive  that  if  a  long  string  of  engine  messages  was 
producing  a  NOTJ/ALID  value  (perhaDS  due  to  some  DP  system  failure),  and 
even  if  the  one  of  the  engines  was  burning  up,  no  warning  would  be  given 
the  flight  engineer.  This  is  clearly  an  unacceptable  circumstance,  and  the 
requirements  could  be  clarified  so  that  the  "NOTJ/ALID"  branch  was  restruc¬ 
tured  to  provide  a  warning  after  some  number  of  consecutive  invalid  inputs. 

2.7.4  Requirements  Data  Base  Documentation 

A  further  benefit  for  management  is  the  capability  of  REVS  to  produce 
consistent  specifications,  even  when  many  changes  are  made  over  short 
periods  of  time  by  many  peoole  in  the  project.  One  computer  >*un  yields  the 
information  needed  for  a  complete  specification  with  all  the  latest  ’revis¬ 
ions.  Of  equal  importance,  if  the  oroper  thoroughness  is  applied  to  every 
revision,  last  minute  panics  do  not  introduce  undetected  errors  in  the 
documentation. 
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Figure  2-11  illustrates  a  typical  printout  showing  the  relationships 
in  a  hierarchical  arrangement  that  presents  a  clear  picture  of  some  of  the 
input  considerations  for  the  Engine  Monitoring  System.  Output  such  as  this 
is  very  useful  for  working-level  documentation.  It  is  compact,  to  the 
point,  and  readable,  although  it  may  not  be  sufficient  for  a  formal 
specification. 
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Figure  2-11  Typical  REVS-Produced  Documentation 

REVS  also  provides  the  capability  to  produce  the  R_NETs  via  a  CALCOMP 
plot.  Figure  2-12  provides  an  example.  Here  again  the  Dlot  incorporates 
all  the  latest  data  base  changes  and,  therefore,  is  consistent  with  the 
specification  printout.  Together,  the  CALCOMP  plot  and  the  automated  text 
output  provide  a  total  understanding  of  what  the  software  is  to  do  (Func¬ 
tional  Requirements)  and  how  well  it  is  to  do  it  {Performance 
Requi rements) . 

SREM  also  can  document  problems  of  which  the  manager  may  want  to 
remain  cognizant.  Usually  at  the  early  stage  of  system  development,  the 
specifications  are  incomplete,  contain  many  ambiguities,  and  leave  several 
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Figure  2-12  Typical  CALCOMP  Plot 

issues  for  future  resolution.  SREM  does  not  require  that  all  omissions  be 
resolved  before  proceeding.  Instead,  a  requirements  engineer  can  proceed 
from  that  which  is  clearly  defined,  and  enter  the  requirements  information 
into  the  data  base. 

Where  the  data  is  not  immediately  available,  is  inconsistent,  or 
otherwise  questionable,  problem  reports  should  be  written  and  entered  into 
the  data  base  for  follow  up.  For  example,  when  R_NETs  are  defined,  the 
requirements  engineer  will  discover  that: 

•  He  doesn't  know  how  certain  MESSAGES  get  processed  under 
particular  conditions. 

•  He  doesn't  know  the  conditions  under  which  a  certain 
output  MESSAGE  is  to  be  produced. 

•  Certain  MESSAGE  contents  are  not  known. 
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These  situations  and  others  like  them  can  be  recorded  as  problems  by 
entering  them  as  DECISIONS  without  CHOICE.  These  DECISIONS  without  CHOICE 
can  be  accessed  via  RAOX  query  and  printed  out  to  present  the  manager  with 
an  automated  problem  list. 

Once  a  CHOICE  is  established,  usually  via  an  answer  from  the  user  to 
a  query,  the  answer  is  recorded  in  the  data  base  as  CHOICE.  Thus,  an  up- 
to-date  history  of  problems  encountered,  still  open,  and  closed  exists  at 
all  times  during  the  SREM  procedures.  This  not  only  provides  a  record  of 
current  status,  but  also  a  valuable  record  of  the  evolution  of  critical 
decisions  on  the  project  effort  for  future  reference. 

2.7.5  Assessing  the  Impact  of  Requirements  Changes 

As  discussed  earlier,  a  means  is  provided  to  establish  traceability 
of  requi rements .  ORIGINATING_REQUIR£MENTs  are  DOCUMENTED  BY  paragraphs  in 
SOURCE  documents  (system  specifications,  interface  specifications,  etc.) 
and  each  key  element  of  requirements  data  base  is  traced  back  to  one  or 
more  of  these  requirements.  Although  it  requires  some  attention  to  detail 
for  the  initial  establishment  of  this  traceability,  there  is  a  real  pay-off 
in  assessing  the  impact  of  requirements  changes.  This  impact  assessment  is 
especially  useful  during  the  configuration  management  procedures  for  a 
proposed  change.  The  traditional,  labor-intensive  page-by-page  search  to 
attempt  to  identify  impacts  is  so  burdensome  that  it  is  seldom  completely 
successful.  As  a  result,  there  is  concern  that  removing  some  portion  of 
the  software  may  impact  the  processing  in  unforseen  ways. 

By  taking  the  time  initially  to  establish  traceability  using  the  SREM 
process,  impact  assessments  of  requirements  changes  are  greatly  eased.  For 
example,  the  following  query  could  be  formed  and  entered  via  RADX  to 
determine  the  impact  of  a  change  in  the  ORIGINATINGJREOMIREMENT  named 
PROCESS_RADAR_INPUTS. 

SET:  ANY  ELEMENT  =  DATA,  FILE,  MESSAGE,  INPUT  INTERFACE, 
OUTPUTJN'ERFACE,  SUBSYSTEM,  R_NET,  SUBNET. 

(Creates  a  set  of  all  the  indicated  RSL  elements) 

SET:  IMPACTED  ELEMENTS  -  ANY  ELEMENT  WHICH  IS  TRACED  FROM 
ORIGINATING  REQUIREMENT7-  ORCCESS  RADAR  INPUTS. 
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(Creates  a  set  of  all  elements  named  in  the  first  set  which 
trace  to  the  indicated  ORIGINATING  REQUIREMENT.  These  are 
the  elements  that  could  be  impacted  by  this  change.) 

LIST:  IMPACTEDJLEMENTS. 

(This  would  result  in  a  printout  listing  all  elements  that 
are  impacted  by  the  change;  that  is,  all  those  in  the 
derived  set  called  "IMPACTED_ELEMENTS'‘ . ) 

Thus,  with  a  single  computer  run,  all  portions  of  the  previous  re¬ 
quirements  engineering  effort  are  identified  that  should  be  re-examined  to 
determine  changes  or  realignment  needed  to  adjust  to  the  new  requirement 
change.  More  important,  however,  is  that  all  the  relationships  these 
elements  have  with  other  unchanged  requirements  is  also  provided  by  the 
run.  This  assures  that  there  is  a  full  understanding  of  what  areas  would 
be  impacted  by  deletions  or  changes  being  contemplated.  A  comparison  of 
this  approach  to  typical  manual  reviews  yields  a  real  appreciation  of  the 
power  of  this  capability. 

2.7.6  Software  Test  Planning 

Software  test  planning  difficulties  are  reduced  by  the  SREM  Analysis 
approach  of  identifying  processing  paths  (R_NETs)  for  various  input  stimu¬ 
lus  (MESSAGES).  It  impacts  both  the  activities  to  be  performed,  and  the 
techniques  for  planning  and  managing  test  activities. 

The  definition  of  all  possible  branches  of  processing,  to  include 
error  paths,  is  a  natural  result  of  defining  the  R_NET  for  each  inout 
stimulus  (MESSAGE).  Thus,  each  resulting  branch  is  a  possible  candidate 
for  a  software  test.  Generally,  however,  a  smaller  set  of  software  sets 
are  designed  by  concentrating  on  the  paths  of  greatest  importance.  A 
VALIDATION_POINT  may  be  added  to  such  branches  to  indicate  the  appropriate 
test  data  recording  points  for  PERFORMANCE_REOUIREMENTS  in  the  process. 

Figure  2-13  illustrates  two  methods  of  determining  PERFORMANCE_ 
REQUIREMENTS  for  various  R_NET  branches.  As  shown  on  the  left,  such  per¬ 
formance  may  be  derived  by  allocation  from  the  performance  described  in  the 
system  requi rements .  In  addition,  there  may  be  a  one-on-one  a d o l i cation  of 
a  PERFORMANCE_REQUIREMENT  to  an  R_NET  branch,  as  shown  on  the  right.  In 
either  case,  each  PERFORMANCE  REQUIREMENT  is  linked  to  (CONSTRAINS)  a 
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Figure  2-13  Determination  of  Software  Test  Reauirements 

YALIDATION_PATH,  which  includes  VALIDA7I0N_P0INTs  for  measuring  the  test 
data  needed  to  determine  that  the  PERFORMANC£_REQUIR£M£NT  has  been  met. 

A  YALIDATION_POINT  is  analogous  to  a  test  point  in  a  piece  of  elec¬ 
tronic  hardware.  It  is  a  port  through  which  information  is  collected  in 
order  to  assess  performance  of  the  function  under  test.  The  information 
RECORDED  BY  a  VALIDATION_POINT  may  be  DATA  or  FILES.  A  PERFORMANCE_ 
REQUIREMENT  has  an  attribute  called  TEST,  which  uses  the  DATA  and  FILE 
information  REC0RDEDJ3Y  the  VALIDATION_POINTs  on  a  VALIDATI0N_PATH  to 
determine  the  pass/fail  criteria  for  the  TEST.  All  the  information  con¬ 
cerning  PERFORMANCE_REQUIREMENTs ,  VALIDATION_POINTs ,  VALIDATION_PATHs ,  and 
TESTs  are  entered  into  the  centralized  data  base. 

This  process  assures  that  needed  tests  are  derived  and  documented  co r 
all  appropriate  processing  paths,  and  that  needed  test  data  will  be  known 
for  each  test.  The  positive  implications  for  this  on  the  attainment  of  a 
testable  software  specification  is  clear  and  significant. 

Two  additional  points  are  approoriate: 

•  In  order  for  the  tester  to  determine  the  tests 
aporopriate  to  allow  proper  verification  that  the 
software  reauirements  are  met,  he  has  to  discover  all 
the  stimulus-response  oaths  of  conseauence  in  the 
system.  No  matter  how  the  reauirements  are  generated, 
the  tester  is  faced  with  this  task.  Thus,  it  makes 


sense  to  develop  the  requirements  using  the  same 
stimulus-response  approach,  and  thereby  to  avoid  double 
analysis  of  the  requirement. 

The  identification  of  testing  is  very  early  in  the 
software  development  because  it  occurs  during  the 
requirements  phase.  Since  it  is  done  in  a  way  that  is 
directly  usable  by  the  tester,  there  is  real  economy  of 
effort  and  early  confidence  of  appropriate  testing  by 
all  concerned. 


2.8  MAINFRAME  REVS  SOFTWARE  CONFIGURATIONS 

The  latest  version  of  REVS,  Version  14,  is  now  installed  and  opera¬ 
tional  at  the  following  sites: 

•-  8MOATC  Advanced  Research  Center  (ARC),  Huntsville, 

A1 abama . 

•  TRW  Defense  and  Space  Systems  Group  (OSSG),  Redondo 
Beach,  California. 

•  Naval  Air  Development  Center  (NADC),  Warminster, 
Pennsylvania. 

This  section  describes  the  REVS  configuration  at  each  of  these  sites  and 
provides  current  data  as  to  the  size  of  the  REVS  software,  in  terms  of 
lines  of  source  code  and  execution  memory  requirements. 

2.8.1  REVS  Source 

The  basic  REVS  program  consists  of  approximately  43,000  lines  of 
PASCAL  organized  into  1108  procedures  and  291  lines  of  FORTRAN  in  3  rou¬ 
tines.  At  NADC,  and  additional  110  lines  of  FORTRAN  in  5  routines  is 
required  to  support  CALCOMP  plotting.-  The  REVS  PASCAL  source  by  functions 
is  as  follows: 


Function 

Source  Lines 

Executi ve 

6921 

CALCOMP  Plotting 

1072 

RAOX 

9665 

RNETGEN 

4031 

TESTER 

2900 

Translator 

7587 

SI  MO  A 

492 

SIMGEN 

9583 

SIMXQT 

622 

2.8.2  TRW  PASCAL  Development  System 

The  PASCAL  development  system  is  used  to  support  installation,  main¬ 
tenance,  and  execution  of  REVS  consisting  of  a  PASCAL  compiler,  run-time 
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library,  and  several  utility  programs.  The  compiler  itself  consists  of 
7503  lines  of  PASCAL  in  143  procedures.  The  run-time  library  consists  of 
43  routines  with  1055  lines  of  PASCAL  and  2235  lines  of  COMPASS.  The  5 
utility  programs  consist  of  2294  lines  of  PASCAL. 

2.8.3  Data  Base  Control  System  (DBCS) 

The  DBCS  consists  of  187  routines  with  a  total  of  10,520  lines.  All 

of  these  are  written  in  FORTRAN  except  for  one  COMPASS  routine  of  141 
lines.  The  inputs  to  the  OBCS  necessary  to  define  the  ASSM  structure 
consist  of  195  card  images.  An  additional  47  card  images  are  reauired  to 
define  the  structure  of  a  REVS  post-processer  data  base. 

2.8.4  Compiler  Writing  System  (CWSl 

The  CWS  consists  of  5  PASCAL  programs  containing  5562  lines  and  3 
standard  input  files  totaling  946  lines  of  PASCAL.  The  definition  of  RSL 
consists  of  a  total  of  7195  source  lines  in  3  files.  This  source  is  a 
mixture  of  PASCAL  code  and  a  syntactic  and  semantic  definition  of  RSL. 

2.8.5  Ancillary  Files 

To  construct  and  support  REVS-generated  simulators  and  post-proces¬ 
sors,  several  additional  files  are  defined.  The  RISF,  an  input  file  to 
SIMGEN,  consists  of  1313  PASCAL  source  lines.  The  post-processor  data  base 
builder  program  and  post-processor  run-time  library  consists  of  137  lines 
of  FORTRAN  in  5  routines  and  454  lines  of  PASCAL  in  23  procedures.  The  RSL 
translator  input  statements  necessary  to  define  the  nucleus  data  base  are 
contained  in  a  file  of  804  card  images. 

2.8.6  BMDATC  ARC  Installation 

At  the  ARC  in  Huntsville,  Alabama,  REVS  is  installed  on  a  CDC  7600 
operating  under  SCOPE  2.1.5.  The  REVS  program  is  organized  into  42  seg¬ 
ments  as  defined  by  137  input  directives  to  the  Segment  Loader.  The  execu¬ 
tion  of  REVS  is  controlled  by  a  764-1 ine  COMPASS  program  which  emulates  the 
macros  defined  for  REVS. 

This  installation  of  REVS  provides  *or  200  639-word  data  base  pages 
in  large  core  memory  (371470g  words  of  LCM)  and  loads  in  a  field  length  of 
1171 16g  SCM  and  377040^  LCM.  A  nominal  REVS  execution  requires  160000g 
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words  of  SCM.  All  REVS  caoabil ities,  including  interactive  ANAGRAPH  ac¬ 
cess,  are  available  at  the  ARC. 


2.8.7  TRW  OSSG  Installation 

REVS  is  operational  on  TRW/TSS  (TRW  computer  center  in  Redondo 
Beach,  California)  for  batch  and  remote  batch  use.  REVS  operates  under  the 
MACE  operating  system  on  the  CDC  CYBER  70/74  and  CYBER  170/174  computers. 
The  REVS  program  is  organized  into  35  overlays  as  defined  by  125  input 
directives  to  the  TSS  loader.  The  execution  of  REVS  is  controlled  by  six 
control-card  PERFORM  files  containing  119  card  images.  A  utility  program 
consisting  of  one  4-line  FORTRAN  routine  and  a  53-line  PASCAL  procedure  is 
defined  to  generate  file  identification  banner  pages. 

Two  REVS  configurations  exist  on  TSS.  One  allows  64  639-word  data 

base  pages  in  central  memory  ( 117700g  words  of  CM),  the  other  allows  100 

data  base  pages  in  central  memory  (174634g  words  of  CM).  The  two  absolute 

programs  required  226236g  and  303302g  words  of  CM  loads.  Nominal  execution 

field  length  requirements  are  250000-  and  325000- ,  respectively. 

o  o 


2.8.8  NADC  Installation 

REVS  operates  on  the  two  CDC  6600s  and  the  CYBER  170/175  at  NADC 
(Warminster,  Pennsylvania)  under  control  of  the  KRONOS  2.1.1  operating 
system.  The  REVS  program  may  be  executed  in  a  batch  or  remote-batch  mode 
and  is  organized  into  45  segments  as  defined  by  357  input  directives  to  the 
CYBER  Loader.  The  execution  of  REVS  is  controlled  by  an  873-line  COMPASS 
program  which  emulates  the  job  central  macros  defined  for  REVS. 

Three  distinct  versions  of  REVS  are  configured  for  the  three  com¬ 
puters,  each  with  a  different  ECS  data  base  page  buffer  size  (200,  400,  or 
500  256-word  pages).  The  memory  requirements  on  the  three  machines  are  as 
follows: 

Machine  Machine  Machine 


A 


C 


ECS  310000g 
CM  Load  105022. 
Nominal  CM  to  execute  150000a 


144000g  372000g 

73570-  105332- 

3  3 

130000g  150000g 


2.9  REVS  IMPLEMENTATION  ON  THE  DEC  VAX  11/780 

As  part  of  a  contractual  effort  from  the  Ballistic  Missile  Defense 
Advanced  Technology  Center  (8MDATC),  TRW  has  installed  REVS  on  a  VAX 
11/780.  The  reasons  for  this  impl ementation  were  that: 

•  It  would  be  applicable  for  the  development  of  the 
Architecture  Development  Language  (ADL)  effort,  which 
allows  the  description  of  arbitrary  architectures  of 
proposed  computer  system  constructs.  These  are  the 
basis  for  modeling  the  system  for  the  support  of 
investigation  of  the  use  of  large  numbers  of  intercon¬ 
nected  microprocessors  on  the  BMDATC  Advanced  Testbed  as 
DP  subsystem  candidates. 

•  With  modification,  it  may  have  application  to  creation 
of  testbed  software. 

§  It  will  support  DDP  application  investigations. 

•  It  will  allow  many  new  users  to  have  REVS  for  their  use 
(where  now,  there  is  limited  availability  on  a  few  CDC 
machines)  such  that  broader  SREM  application  is 
possible. 

As  part  of  this  effort,  TRW  was  to  compare  CPU  times  between  the  VAX 
and  the  CDC  7600,  to  determine  where  the  VAX  CPU  time  was  accumulating 
during  the  execution  of  the  REVS  program,  and  to  assess  how  these  run  times 
could  be  reduced.  The  ratio  of  CPU  times  varied  between  50  to  1  and  400  to 
1,  with  test  cases  averaging  128  to  1.  The  heaviest  usage  was  during  RADX 
executions,  and  since  most  of  the  test  cases  involved  RADX,  there  was  a 
bias  in  the  run  times  ratio  torward  the  upper  extremes.  Because  run  time 
differences  of  about  20  to  1  were  expected,  research  was  needed  to  investi¬ 
gate  the  reasons,  and  was  an  important  part  of  the  study. 

As  a  result  of  efforts  under  the  BMDATC  study,  improvements,  amount¬ 
ing  to  about  50  percent  reduction  in  the  above  run  time  differences  were 
attained.  Further  redactions  will  reauire  the  optimization  of  the  data 
base  management  system  (optimization  was  not  a  part  of  the  study  effort). 
The  results  of  the  BMDATC  effort  have  been  excerpted  from  the  final  reoort 
and  printed  in  Appendix  A  for  those  desiring  added  information. 


3.0  DESCRIPTION  OF  THE  SREM  APPLICATION  TO  THE  MOM  DFSR 


3.1  INTRODUCTORY  REMARKS 

The  purpose  of  this  section  is  to  present  a  profile  of  our  efforts  to 
apply  SREM  to  the  DFSR.  After  this  introduction,  and  a  discussion  of  the 
scope  of  the  effort,  a  description  of  the  SREM  process  will  be  presented  to 
describe  our  definition  of: 

t  Interface  elements. 

•  Stored  data . 

•  R_NETs . 

•  Traceability. 

In  each  of  these  descriptions,  the  appropriate  RSL  concepts  will  be  intro¬ 
duced,  together  with  a  description  and  illustration  of  the  approach  to  the 
definition  process.  A  comparison  of  the  resulting  RSL  elements  to  those 
described  in  the  DFSR  will  then  be  provided  followed  by  a  discussion  of 
problems  encountered. 

Following  that,  and  in  preparation  for  the  discussion  of  our  eval¬ 
uation  of  the  requirements  data  base,  a  tutorial  on  RADX  and  its  use  for 
this  evaluation  will  be  presented.  This  will  be  followed  by  the  results  of 
our  RADX  evaluation. 

Finally,  an  analysis  will  be  presented  concerning  how  the  time  of  the 
software  engineers  assigned  to  this  effort  was  applied.  This  will  be  based 
on  the  diaries  maintained  during  the  MOM  DFSR  evaluation.  The  analysis 
will  include  statistics  of  interest  concerning  the  amount  of  effort  needed 
for  evaluation  of  a  specification  of  this  size,  and  how  it  was  distributed 
to  the  various  phases. 


3.2  SCOPE  OF  THIS  EFFORT 

The  evaluation  of  the  OFSR  under  this  contract  was  constrained  by 
several  factors  encountered  during  the  period  of  performance.  The  size  of 
the  specification  package  was  significant  for  the  time  available  and  the 
level  of  effort  possible  under  the  contract.  '  In  addition,  the  specifi¬ 
cations  possessed  two  unexpected  conditions: 

•  There  was  a  significant  quantity  of  errors,  beyond  the 
number  that  was  anticipated. 

•  There  was  an  unexpectedly  large  auantity  of  input 
MESSAGES  to  be  considered,  since  each  individual  data 
item  was  actually  a  separate  input  for  which  processing 
was  defined. 

3.2.1  Approach  to  Overcoming  Delays  Caused  by  the  High  Error  Count 

We  found  such  significant  inconsistencies  between  the  text  which 
described  the  required  processing,  the  functional  flowcharts,  and  the 
Decision  Logic  Tables  (DLTs)  that  we  failed  when  we  first  attempted  to 
harmonize  these  three  descriptions  in  order  to  synthesize  the  intent  of 
each  portion  of  the  processing.  Complicating  this  problem  was  the  fact 
that  no  user  existed  whom  we  could  query  to  determine  the  true  intent. 
Rather,  we  were  required  to  provide  our  own  answers.  This  turned  out  to  be 
so  time  consuming  that  we  had  to  find  a  different  approach  if  there  was  to 
be  any  chance  of  completing  the  effort  in  the  time  available. 

As  a  result,  it  was  clear  that  we  would  have  to  pick  one  of  the  three 
conflicting  sets  of  processing  descriotions  and  use  it  in  isolation  from 
the  others  in  applying  the  SREM  methodology.  After  evaluation  of  each  of 
the  possible  sources,  we  selected  the  Decision  Logic  Tables  (DLTs)  for  use, 
primarily  because  they  presented  the  most  complete  processing  description 
of  the  three. 

In  selecting  the  DLTs,  we  consciously  decided  to  ignore  the  inconsis¬ 
tencies  between  text,  functional  flow  diagrams,  and  DLTs.  Time  did  not 
permit  such  an  evaluation,  although  a  few  differences  that  were  uncovered 
during  DLT  evaluation  were  documented  in  Trouble  Reports.  We  are  satisfied 
that  many  added  Trouble  Reports  would  have  resulted  if  we  had  evaluated 
text  and  functional  flow  diagram  consistency  as  carefully  as  we  did  the 
DLTs.  These  ignored  inconsistencies  would  only  have  reflected  format 
content  inconsistencies  within  the  written  specification,  rather  than  the 
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more  important  adequacy  and  internal  consistency  of  the  processing  logic. 
Thus,  our  attention  was  focused  within  and  between  the  DLTs,  and  between 
the  DLT  definition  of  data  identification  compared  to  that  within  the 

following  DFSR  Annexes: 


• 

Annex  A: 

Input  Descriptions. 

• 

Annex  B: 

Output  Descriptions. 

• 

Annex  C: 

Information  Elements. 

Annex  D: 

File  Description. 

However,  the  decision  to  concentrate  on  OLTs  only  partially  solved 
the  size  of  the  problem.  When  we  followed  the  approach  of  analyzing  the 
OLTs,  the  error  count  still  turned  out  to  be  beyond  that  originally  ex¬ 
pected,  and  considerably  more  time  was  necessary  for  Trouble  Report  prepar¬ 
ation  and  coordination  than  had  been  contemplated.  As  a  result,  further 
constraints  on  the  effort  were  found  to  be  needed  so  as  to  allow  completion 
within  the  allotted  schedule.  At  this  point,  it  was  determined  that  the 
goals  of  this  effort  would  be  duplicated  if  SREM  was  applied  to  both  the 
MOM  and  MPOM  DFSRs.  The  format  and  contents  of  the  MPOM  DFSR  was  similar 
to  that  of  the  MOM.  It  was  however,  smaller  and  less  complex,  since  the 
man-smachine ,  real-time  aspect  of  the  MOM  specification  was  missing,  and 

f 

since  there  were  fewer  input  and  output  messages  and  global  files  to  con¬ 
sider.  Consequently,  since  the  MOM  DFSR  was  more  varied,  and  since  it 
contained  far  more  processing  requirements  than  the  MPOM  DFSR,  it  was 
decided  to  concentrate  on  the  MOM  OFSR  for  our  SREM  application 
dembnstration. 


i  THE  SREM  methodology  was  designed  to  treat  each  group  of  input  infor¬ 
mation  received  or  transmitted  by  the  DP  as  a  MESSAGE.  Each  input  MESSAGE 
provides  a  processing  stimulus,  the  response  to  which  is  defined  on  an 
R_NET.  In  the  case  of  the  MOM  OFSR  real-time  processing,  each  of  several 
hundred  data  items  is  input  to  the  system  in  response  to  a  prompt  cue 
provided  by  the  OP  to  the  operator  after  he  has  successfully  input  the 
preceding  data  item  in  the  proper  format  and  containing  a  legal  value. 

/ 


3-3 


In  terms  of  the  current  methodology,  each  DATA  item  thus  input  act¬ 
ually  is  a  separate  RSI  MESSAGE  and  presented  the  need  to  define  a  process¬ 
ing  path  for  each  one.  However,  the  SREM  process  contemplates  the  logical 
processing  of  a  MESSAGE,  and  not  necessarily  the  detailed  means  for  imple¬ 
menting  the  correct  construction  of  these  MESSAGES  as  defined  for  indivi¬ 
dual  data  inputs.  It  was  clear  that  the  desired  output  products  of  this 
effort  could  not  be  attained  if  each  such  data  input  was  treated  as  an 
individual  input  MESSAGE.  A  way  had  to  be  found  to  shortcut  this  problem 
without  adversely  impacting  these  desired  products.  We  concluded  that  we 
should  treat  this  problem  in  a  more  summary  fashion,  as  described  in  the 
following  paragraphs. 

First,  we  decided  to  describe  the  process  of  individual  data  entry 
required  during  the  specified  real-time  processing  in  a  generic  fashion, 
since  each  data  item  input  was  essentially  processed  in  the  same  way.  That 
is,  regardless  of  which  data  item  was  input,  it  was  to  be  subjected  to  a 
format  and  legal -value  check,  and  an  error  message  was  to  be  produced  if 
incorrect.  If  the  input  was  correct,  the  data  was  to  be  retained  and  the 

next  data  input  prompt  was  to  be  displayed.  Or  if  an  error  was  detected, 

the  current  prompt  was  to  be  redisplayed.  There  also  was  the  need  to  allow 
the  operator  to  skip  a  prompt  if  it  described  an  optional  input  data  item, 

or  to  allow  him  to  select  the  previous  prompt  if  he  desired. 

In  order  to  describe  the  generic  approach  of  processing  data  inputs, 
it  was  necessary  to  accomplish  bookkeeping  of  information  concerning  what 
data  item  is  being  processed,  what  the  next  prompt  should  be,  what  the  last 
prompt  was,  what  the  legal  value  and  format  for  the  item  being  input  was, 
what  error  code  was  appropriate  if  an  error  was  detected,  plus  other  infor¬ 
mation  necessary  to  allow  the  DP  to  recognize  what  process  was  underway  and 
what  process  was  to  follow.  This  capability  was  implemented  by  grouping 
the  needed  bookkeeping  information  into  ENTITY_CLASSes,  and  treating  the 
input  of  each  data  item  as  a  single  generic  input  MESSAGE.  The  result  can 
be  seen  in  the  regeneration  of  the  SAMS  requirement  in  Appendix  3. 

The  generic  impact  approach  for  data  input,  as  described  above, 
allowed  the  remainder  of  our  software  engineering  to  treat  the  processinq 
described  in  the  DFSR  in  a  more  summary  fashion.  Each  real-time  process 
(XMA,  XM8,  etc.)  was  treated  as  if  the  stimulus  for  its  processing  was  a 
single  MESSAGE  (as  defined  in  Annex  A  of  the  DFSR)  and  each  such  MESSAGE 


which  was  MADE  BY  DATA  for  which  ail  values  were  legal  and  correctly  for¬ 
matted.  This  was  feasible,  since  each  of  the  individual  data  items  in  the 
MESSAGE  had  initially  been  subjected  to  the  tests  we  described  in  the 
generic  process  for  testing  these  individual  inputs.  Thus,  the  process 
described  in  the  net  for  XMA  assumes  that  all  the  DATA  encountered  is  of 
the  correct  format  and  possesses  a  legal  value.  As  a  result,  the  process-, 
ing  logic  described  in  the  R_NET  assumes  "correct"  data  and,  therefore, 
does  not  include  the  processing  shown  in  the  DLTs  to  assure  that  the  data 
are  correct  and  legal,  nor  the  prompts  for  the  next  ooerator  entry.  As 
stated,  all  of  this  processing  was  covered  in  the  generic  definition  of  the 
input  process. 

There  were  occasions,  however,  where  the  format  of  an  input  DATA  item 
was  not  constant  and,  therefore,  could  not  be  checked  during  the  generic 
input  process  because  specific  processing  was  necessary  to  determine  the 
correct  format.  For  example,  in  the  XMA  and  XMB  Drocessing,  the  PRT_N0_FLD 
may  have  any  of  several  formats,  depending  on  whether  it  contains  a 
National  Stock  Number,  a  manufacturer' s  part  number,  or  a  commerical  vehi¬ 
cle  code.  In  a  case  such  as  this,  different  format  checks  are  necessary 
and  the  processing  described  in  the  R_NET  must  determine  which  format  is 
appropriate  and  whether  the  DATA  item  actually  has  that  format.  All  other 
DATA  items  in  the  input  MESSAGES  that  did  not  possess  variable  formats  were 
subjected  to  the  generic  input  processing  previously  described. 

This  approach  served  to  reduce  the  application  time  for  developing 
the  requirements  data  base  so  that  the  desired  products  of  this  demonstra¬ 
tion  could  be  attained.  However,  this  approach  (if  applied  to  a  "real" 
system  under  development)  might  create  some  problems,  in  that  R_NETs  so 
derived  don't  literally  match  the  approach  outlined  in  the  specification. 
Although  the  approach  used  is  a  true  representation  of  the  overall  required 
processing,  the  literal  ( rather  than  generic)  representation  of  each  data 
item  entry  as  a  separate  MESSAGE  would  be  preferable  for  verification  of  an 
actual  system  under  development.  It  should  be  recognized,  however,  that 
added  resources  (including  more  time)  would  be  necessary  for  application  of 
SREM  at  the  greater  level  of  detail  that  would  be  required. 
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3.2.3  Impact  of  the  Selected  Approaches 

Based  on  the  size  and  scope  of  the  MOM  DFSR,  it  is  clear  that  many 
man-years  were  devoted  to  its  completion.  Considerable  manual  effort  was 
clearly  needed  to  organize,  cross-reference,  and  produce  the  specifica¬ 
tions.  A  very  small  portion  of  the  probable  original  effort  expended  on 
this  specification  was  available  to  accomplish  this  SREM  engineering  analy¬ 
sis.  Although  time  pressures  required  us  to  modify  our  approach  slightly, 
the  resulting  requirements  data  base  and  its  RADX  evaluation  is  complete 
and  we  have  high  confidence  that  we  have  identified  all  the  important 
deficiencies,  and  nearly  all  of  the  less  important  ones  that  exist  in  the 
MOM  DFSR  Decision  Logic  Tables.  Thus,  our  applied  approach  has  provided 
the  products  desired  under  this  contract  in  every  particular. 


3.3  DEVELOPMENT  OF  INTERFACE  ELEMENTS 

The  initial  phase  in  defining  the  requirements  of  the  MOM  DFSR  re¬ 
quired  the  identification  of  the  INPUT_INTERFACEs  and  OUTPUT_INTERFACEs 
which  connect  the  data  processor  (DP)  with  external  devices  (SUBSYSTEMS  in 
RSL).  Once  the  interfaces  were  identified,  the  MESSAGES  passing  through 
them  and  the  contents  of  these  MESSAGES  were  defined.  These  items  were 
recorded  in  the  requirements  data  base  as  they  were  identified.  Table  3.1 
lists  the  RSL  definition  of  the  element  types,  the  relationships,  and  the 
complementary  relationships  used  in  the  development  of  interface  elements. 
Figure  3-1  illustrates  the  inter-relationships  of  these  defined  items. 

Table  3.1  RSL  Definitions  Used  in  the  Development  of  Interface  Elements 


DEFINITION  OF  ELEMENTS 

SUBSYSTEM 

A  PART  OF  THE  SYSTEM  WHICH  COMMUNICATES  WITH  THE  DATA 

PROCESSING  SUBSYSTEM. 

:nput_interfac£ 

A  PORT  BETWEEN  THE  DATA  PROCESSING  SUBSYSTEM  AND  ANOTHER 
SUBSYSTEM  THROUGH  WHICH  DATA  IS  PASSED  TO  THE  DATA  PRO¬ 
CESSING  SUBSYSTEM. 

OUTPUTJNTERFACE 

A  PORT  BETWEEN  THE  DATA  PROCESSING  SUBSYSTEM  AND  ANOTHER 

PART  OF  THE  SYSTEM  THROUGH  WHICH  DATA  IS  PASSED  TO  THE 

OTHER  SUBSYSTEM. 

MESSAGE 

AN  AGGREGATION  OF  DATA  ANO  'ILES  THAT  PASS  THROUGH  AN 

INTERFACE  AS  A  LOGICAL  UNIT. 

FILE 

AN  AGGREGATION  OF  INSTANCES  OF  DATA,  EACH  INSTANCE  OF  WHICH 

IS  TREATED  IN  THE  SAME  MANNER. 

DATA 

A  SINGLE  PIECE  DF  INFORMATION  OR  SET  OF  INFORMATION  REQUIRED 

IN  THE  IMPLEMENTED  SOFTWARE. 

DEFINITION  OF  RELATIONSHIPS 

1  CONNECTS  '0  1  IDENTIFIES  WITH  WH I CH  SU3SYSTEM  THE  INPUT  INTERFACE  OR 

|  (CONNECTED  TO)  j  OUTPUTJNTERFACE  CCMWUN I CATES. 

PASSES 

(PASSED  THROUGH) 

IDENTIFIES  THE  USAGES  *HICH  ARE  34SSED  THROUGH  THE  INTER¬ 
FACE. 

MAXES 
fMAOE  3Y ) 

INOICATES  THAT  *HE  DATA  OR  FILE  IS  A  .OGICAL  COMPONENT  DF  THE 
MESSAGE. 

CONTAINS 
(CONTAINED  IN) 

IDENTIFIES  THE  MEMBERS  DF  EACH  INSTANCE  IN  A  -IL£;  DATA  MAY 

BE  CONTAINED  IN  DNL'  DUE  - CL£ . 

INCLUDES 
'  INCLJQEQ  IN) 

INOICATES  A  HIERARCHICAL  RELATIONSHIP  BETWEEN  DATA,  'HAT  IS 

DATA  INCLU0E3  DATA. 

Figure  3-1  Interface  Element  Interrelationships 
3.3.1  Subsystem  Definition 

To  identify  the  SUBSYSTEMS,  we  reviewed  the  text,  the  functional  flow 
diagrams,  and  the  input  and  output  descriptions.  The  primary  source  for 
identification  of  the  SUBSYSTEMS  was  the  input  descriptions  of  Annex  A  and 
the  output  description  of  Annex  B.  The  SUBSYSTEMS  that  have  been  defined 
are  listed  in  Table  3.2.  These  same  sources  produced  the  information  as  to 

Table  3.2  SUBSYSTEMS  Identified  in  the  MOM  DFSR 


subsystem:  «om _c’T. 
CONNECTED  to: 

output  .interface 

:  TO_'*On_C  *t. 

subsystem:  n0n_<S''3QaPQ. 
CONNECTED  to: 

i.NP'jr_iNrc3F4CE: 

r 3UN_nOM_<ET30ApO . 

SUhSySTEn:  rC«_,,i4ii_'*£QlA. 
CONNECTED  TO: 

INP'J  T  _I.N  f  EPF  ACE  : 

p  3Qn_'*OH_*4G_-E0  I  A  . 

OUTP'JT.lNr^f  xzt 

:  TO_>*On_«»G_<iCQ  1  a  , 

SUBSySTEn:  CnTEP . 

CONNECTED  to: 

OUTP'JT.EnTSPPaCS 

:  TU_YOM_aPtNTEB. 

i 

SUBSYSTEMS 

transmitted  information 

to  the  MOM  USER  data 

( INPIJT_INTERFACE  in  RSL)  and  which  received  information  (OUTP'JT_IMTERFACE 
in  RSL). 
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3.3.2  Interface  Definition 

An  INPUT_INTERFAC£  in  RSL  denotes  a  link  through  which  information  is 
communicated  into  the  OP.  An  OUTPUT_INTERFACE  is  one  through  which  infor¬ 
mation  is  communicated  from  the  OP.  The  relationship  of  each  type  of 
interface  is  that  it  is  connected  to  a  SUBSYSTEM.  Each  interface  passes 
one  or  more  messages,  but  to  prevent  ambiguity,  the  methodology  states  that 
a  specific  MESSAGE  may  pass  only  one  interface. 

3.3.3  MESSAGE  Definition 

MESSAGES  are  the  aggregation  of  DATA  and  FILEs  that  are  communicated 
as  logical  units  across  the  interfaces.  While  these  MESSAGES  are  made  by 
DATA  and  FILE  information,  a  single  DATA  item  or  FILE  may  be  used  to  make 
several  MESSAGES.  The  DATA  and  FILEs  that  an  interface  communicates  are 
those  that  MAKE  all  the  messages  that  PASS  through  the  interface.  A  FILE, 
as  used  here,  is  a  repetitive  set  of  one  or  more  DATA  items.  The  major 
source  of  MESSAGES  and  their  contents  also  was  Annexes  A  and  B. 

Each  input  and  output  file  in  Annexes  A  and  B  has  been  defined  as  an 
RSL  MESSAGE.  Where  necessary,  the  RSL  MESSAGE  name  was  slightly  modified 
from  Input/Output  File  Names  in  the  Annexes  to  insure  uniqueness.  For 
example,  the  suffix  MSG_IN  was  added  to  identify  the  input  messages  while 
the  suffix  MSG_0UT  was  utilized  in  a  like  manner  to  identify  the  output 
messages.  Because  RSL  allows  the  use  of  a  synonym  to  shorten  lengthy 
titles,  the  unique  number  provided  for  each  Input/Output  description  in  the 
DFSR  Annexes  (e.g.,  12  01  KZ)  was  employed  to  fulfill  this  role.  Where 
possible,  the  data  element  abbreviations  provided  in  the  Annexes  were  used 
as  the  RSL  DATA  names  within  each  RSL  MESSAGE.  In  order  to  assure  non¬ 
ambiguity,  each  DATA  item  is  named  uniquely.  It  was  necessary,  therefore, 
to  slightly  modify  the  abbreviated  data  names  in  Annexes  A  and  3,  and  to 
add  the  suffixes  IN  or  OUT,  respectively. 

In  RSL,  a  MESSAGE  is  MADE  BY  DATA  which  may  include  other  DATA.  A 
major  sumnary  DATA  item  made  each  MESSAGE.  It  included  all  of  the  data 
elements  contained  in  the  input  description  of  Annex  A.  This  allowed  use 
of  the  suimary  item  in  the  SREM  definition  of  processing,  but  the  system 
still  understood  that  all  the  INCLUDED  DATA  were  involved.  An  example  of 
all  the  rel ationshi ps  produced  from  the  requirements  data  base  for  the 
input  MESSAGE:  WRK  0R0  REGI STRATI 0N_0ATA  MSG_IN  is  shown  in  Figure  3-2. 
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message :  ■«K_3^o_semsTRAT:oN_OArA_>4S«_:N 

equated  to 

StnONTM:  I2_3lw<Z 

MAoe  ar 

qaTa:  HOH_,<T90_,HSu_TrP£ 

oaTaj  n«K_o*io-j?e5israAr  ia«  j>ArA_,isa_it«_i(H<fo 
INCLUOE5 


Oata: 

CUNO  JDSG  _u£  I  *8  _CUS  T  N 

OATA: 

OIC.iN 

Oata: 

£NO_ [ TEN  _CO«e_ I NO_fLO_lN 

OATa: 

tuuiP_HeoNj:a,i* 

Oata: 

tuuip_s£*j.ci _ ;on-'«o_[n 

Oata: 

?  U.ZJ.HP  r_ACT_:o_:  * 

Oata: 

I0£NT_*4O_C0_In 

Oata: 

INTHa.SHOP  CO  I* 

oata: 

IPO.IN 

OATa: 

I  TEH_jVOM£N_i  TEn_nO'JN_/LQ_2n 

Oata: 

MAT_P£ON_p£PT_DSG_IN 

Oata: 

P«T_NO_ftO_2N 

OATa: 

S6a_NQ_IM. 

Oata: 

U'l  C_CUST  _IN 

Oata: 

vMC_SPT_In 

includes 

oata:  OESca_osa_ui;_:N 
data:  P9*ir_owa_asG_j  ic.i't 
a  *  r  a :  svc_osa.jic_iN 


Figure  3-2  Hierarchical  Definition  of  the  MESSAGE: 

WRK_ORD_REGI  STRATI  ON  _DATA_MSG_I  N 
3. 3. 3.1  Input  MESSAGE  Definition 

Frequently,  it  was  necessary  that  an  Annex  A  input  description  be 
structured  into  more  than  one  RSI  MESSAGE.  An  example  of  this  situation  is 
provided  by  the  input  description  for  "Work  Order  Requirements  Data".  This 
input  description  addresses  three  distinct  subjects  --  Tasks,  Parts,  and 
Supplemental  Parts.  Each  of  these  subjects  reauires  a  separate  entry  into 
the  DP,  and  each  is  MADE  3Y  different  DATA  items.  Thus,  under  the  SREM 
rules,  these  are  three  separate  input  MESSAGES,  and  each  is  subjected  to 
separate  processing  logic.  Accordingly,  this  requirement  with  the  input 
title  "Work  Order  Requirements  Data"  in  Annex  A  resulted  in  the  following 
three  RSL  MESSAGES: 

WRK_ORD_REQMTS_OATA_TASK_MSG_IN 
WRK_ORD_REOMTS_DATA_PARTS_MSG_IN 
WRK_ORD_RECMTS_DATA_SUPL_PARTS_MSG_IN 
Table  3.3  provides  a  comparison  of  all  of  the  Annex  A  input  descriptions 
with  the  resultant  RSL  INPUT  MESSAGES. 
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Table  3.3  Comparison  of  Annex  A  Input  Descriptions  and  Equivalent  RSI 
MESSAGE  Names 


SAMS  3FSR  ANNEX  A 

RSL 

INPUT  TITLE 

10  CQOE 

SYNONYM 

INPUT  MESSAGE  NAME 

WORK  ORDER  REGISTRATION  DATA 

12  01  <2 

I2_01_K2 

4RK_ORO_REGISTRATION_OATA_MSG_m 

NORA  ORDER  REGISTRATION  ADDITIONAL  OATA 

12  02  <2 

IZJZJZ 

WRK  ORD  REGISTRATION  AOOL  OATA 

RPRJCGJN  ~ 

I2_02A_X2 

m  ORO  REGISTRATION  AOOL  OATA 

C&_MfSJN 

NORA  OROER  REQUIREMENTS  DATA 

12  03  <2 

I2_03_X2 

jrk_ordjeomts_3ata_task_msgjn 

I2_03A_X2 

WRK_ORO_REQMTS_OATA_PARTS_MSG J N 

I2J338JC2 

MRK_QRO_REQMTSJ)ATAJUPL_PARTS_MSGJN 

NORA  OROER  CONSUMPTION  OATA 

12  04  <2 

1 2_04_<2 

WRK_ORO_CONSUMPTIQN_OATA_LAaOR_MSG_IN 

I2_04A-X2 

jrk_qrq_consumpt;qn_sata_parts_msg_:n 

I2_04B_X2 

wrk_qro_:qnsumptiqn_sata_:ask_msgjn 

NORA  OROER  STATUS  OATA 

12  OS  <2 

I2_05_X2 

prx_orojtatus_oata_msg_:n 

MAINTENANCE  PROGRAM  OATA 

12  06  XY 

I 2_C6_<2 

MA  INT_3POGRAM_SATA_MSG_:  N 

MAINTENANCE  PROGRAM  REQUIREMENTS 

12  07  3M 

I2_07_9M 

MA  INTjAROGRAMJEOUI  REMENTSJKG  JN 

REPAIR  PART  MORTALITY  OATA 

12  08  8M 

I2_08_aM 

REPA I  R_P  ART  ^MORTAL  ITYJSATAJMSGJN 

PART  NUMBER  CHANGE  OATA 

12  12.  <Y 

12  J  2  JIT 

?art_num8er_:hange_sata_msg_;n 

PARTS  RECEIPTS/STATUS/RECONCILIATION 

12  13  <2 

I2_13_X2 

?rts_rcpts_status_reconcil_rc?t_msg_:n 

1 2_T  3A_KZ 

prts_rc?tsjtatus_reconc:l_res?on_msg_:n 

I2J38_XZ 

PRTS_RCPT3_5TATUS_REC0NC:l_STATUS_MSGJN 

SUPPLY  STATUS 

12  IS  30 

I2JSJ0 

supplyjtatus_msg_:n 

SHIPMENT  STATUS 

12  16  30 

1 2 J  S_30 

SHIPMENT_5TATUS_MSGJN 

I  SSL  adjustment 

12  17  XT 

I2J7_<Y 

SHOP_5TOex_LlST_AOJUSTMENT_A_MSG_IN 

I 

12  J  7A_XY 

SHOP  JT0CX_LIST_AOJUSTMENT_3_MSGJN 

12  J  73 _ <Y 

shop_stoc:x_l  :  $t_aojustment_:_msg_:  n 

1 

I2J70-XY 

3ENCH_3TQCK_AOJUS7MENT_3_mSGJ.N 

12  J  7E_<Y 

3ENCH_5TOC:X_AOJUSTMENT_E_MSG_:n 

12  J  7P__<Y 

3ENCH_$70CX_AOJUSTMSNT_;_*SG_:n 

IC  J  7G_<Y 

3ENCH_ST0CX_A0JUSTMENT_S_aSG_:N 

SUPPLY  RECONCILIATION 

12  13  3M 

I2J3JM 

supply_reconc:liation_;n_«sg_:n 

I2J3A_SM 

supply  _rec3nc:l:a7I3n_ap_ms6_:n 

I  *QRK  SROER  PARTS  ADJUSTMENT 

12  SO  <R 

::jo_xr 

«rk_;ro_:>arts_aojustment_msg.:n 

j  EQUIPMENT  RECALL  VEH  ITEM 

12  20  <y 

:;_:ca_<y 

eouip_recall_'!Ea_:te.m_a_<sg_:n 

! 

i 

::_sc8_a 

equ  i  ?_recall  jiew_:  tem_3_'*sg_;n 

EQUIPMENT  RECALL  REQUIREMENTS 

::  so  >m 

::js_iM 

ECU  !?_RECAL.  JECU  IREMEN"  -"SO N 

|  ALT'SRO  REQUIREMENTS 

!2  'A  V 

’.ZJAJ'f 

AL  :  J  RO  J  ECU  I R  EMEN  75  _  ’S  0  _ .  :i 

j  -'COAT  PILE  ADJUSTMENT 

12  AO  <Y 

:;_ao_<y 

p’.OAT  1  .EJOJUSTMEN  T  J*SG_:  N 

JSAGE  SATA 

12  E0  <R 

::jo_<r 

JSA5E_7ATA_MSG_:n 

USAGE  DEVICE  COMPONENT  CHANGE 

12  51  <Y 

::ji_<y 

jsage_:evice_:omponentjhange_msg_:m 
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Table  3.3  Comparison  of  Annex  A  Input  Descriptions  and  Equivalent  RSI 
MESSAGE  Names  (Continued) 


SAMS  DFSR  ANNEX  A 

RSL 

INPUT  TITLE 

10  COOE 

SYNONYM 

INPUT  MESSAGE 

USAGE  EXCEPTION  LIST 

12  52  SR 

I2_52_3R 

USAGE  JXCEPT I  ON_L  I  STJS6JN 

USAGE  OATA  SURVEY  (ANNOTATED) 

12  53  4R 

I2_53_AR 

USAGE_OATAJURV£Y_ANNOTATED_NS6JN 

TASK  PERFORMANCE  FACTOR  AOJUSTNENT 

12  60  KY 

I2_60_KY 

TASX_PERFORMANCE_FACTOR_ADJUSTMENT_MSG_!N 

AORK  center  LABOR 

12  70  KY 

12_70_KY 

NORKJENTERJABORJCGJN 

TABLE  BUILD 

12  96  KY 

I2J6AJY 

TABLE  JUILD_ECC_MSG_IN 

I2_96B_KY 

TABLE  JU 1  LDJRK  JEQ  _STA_MSG  J  N 

1 2 _ 96C _ IKY 

TABLE  JUlLO_STOCK_STOCKAG£  l£V£L_NSG_IN 

12_960_KY 

TABLE  JU  I LO _ I NOU  l  RY  _ACT  I  ON  _MSG_IN 

I2J6E-KY 

TABLE  JUILD_WORK_CENTER_MSG_I  N 

INQUIRY 

12  97-  KY 

I2J7AKY 

INQUIRY  _MSGJN 

12_978_KY 

I NQU 1 RY  ^SUMMARY  _mSG_IN 

PARAMETER 

12  9B  KY 

12  98A  KY 
-  - 

PARAMETER  JOLLQUJPJSGJN 

I2J88KY 

PARAMETER  JORKJRDERJSGJ  n 

12J8CKY 

PARAMETER  JORKLOADJACKLOGJGEjMSGJN 

I2J80_KY 

parameter_partsjtatusjetail_msgjn 

12J8E-KY 

PARAMETER  JEPORT  JON  TROLJSGJN 

I2_98F_KY 

PARAME  T£  ft  JYORS  JORM_OA  TA_MSu_IN 

I2J8GJY 

PARAMETERJREVIOUSJYCLEJATE  JSGJN 

I2_98H-KY 

PARAMETER  JUTYJ0URSJ1SGJN 

CROSS  REFERENCE  TRANSACTION 

12  79  KY 

1 2_39A_<Y 

CROSS  JEFERENCE  ^TRANSACT  I  ON  _A_MSG_1  N 

12J9BKY 

CROSSJEFERENCEJRANSACTION  JJSGJN 
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3. 3. 3. 2  Output  MESSAGE  Definition 

The  output  descriptions  provided  in  Annex  3  were  the  source  for  RSI 
OUTPUT  MESSAGES.  An  example  of  an  output  MESSAGE  from  the  reauirements 
data  base  is  shown  in  Figure  3-3.  As  with  the  input  descriptions  of  Annex 
A,  the  messages  defined  by  the  output  descriptions  in  Annex  B  sometimes  had 


*eSSAG£:  FCOAT_SrArua_ne.f,UKr_risa_UvjT 

SuuArto  ro 

Synonym 

c 

fvi 

*— 

o 

L 

-< 

JQCUntNTEQ 

ar 

SOuHCE: 

sa*s_i  j»AG£_aa 

*ao€  sr 

data: 

au  r  nw2Q_JN  TY  _l o_*y 

uaTa: 

OATt  j»ee?_u«o_iu_<*T 

QaTa: 

OaTa: 

I  T£r_NO«tM_I  Ti«_NOUN_FLL)_ia 

DATA : 

3wHANO_0‘irr_0KF_iu_»r 

OaTa: 

3tYr_NO_p'_Q_10_AT 

OaTa: 

3TY_£NOH_iO_%Y 

OaTa: 

3rr_£QH_io_*r 

data: 

Jlc_SPr_io_*r 

OaTa: 

JN  l  T  _NA*t _se  T  _1  U  Y 

Figure  3-3  Hierarchical  Definition  of  the  Output  MESSAGE: 

FLOAT_$TATUS_REPORT_MSG_OUT 

to  be  divided  into  more  than  one  RSI  MESSAGE.  This  implied  reauirement  was 
determined  after  the  completion  of  an  analysis  of  the  hardcopy  formats 
provided  in  Annex  B.  These  formats  show  that  portions  of  the  outputs  are 
single  item  entries  (such  as  the  heading  information),  while  other  portions 
provide  fields  of  repetitive  information.  An  example  of  a  MESSAGE  that 
does  not  have  to  be  divided  is  shown  in  Figure  3-4.  In  RSI  terms,  the 
heading  information  is  a  group  of  DATA  items  (UIC_SPT,  WORK_CENTER_NR, 

DATE,  etc.).  Following'  the  header,  there  are  three  groups  of  repetitive 
sets  of  DATA.  These  groups  are:  1)  WORK  ORDERS  IN  PROCESS,  2)  WORK  ORDERS 
AWAITING  WORK  CENTER,  and  3)  WORK  ORDER  AWAITING  PARTS.  Within  each  of 
these  groups,  a  separate  line  of  information  (several  DATA  items)  is 
printed  for  each  Work  Order  that  meets  the  criteria  for  the  arouo.  thus, 
in  RSL,  each  group  is  a  FILE  containing  multiple  instances  of  DATA  f one 
instance  for  each  line  to  be  printed  under  the  group).  Accordinalv,  the 
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NfSiAje.:  «3M<_CEnT£.-<_SumMa,<Y_m:5u_3oT 

iQUA  7E0  TO 

SYNONYM:  o 2_0i_*U 

•40E  »r 

F  £l_£  :  ,«0  pi  ft  _C£.N  _30M  A  _,«»<*_,»  /(  7(j_p  4«  7  a  _a  jO_JU  7  _I  \ir  j 

CONTAINS 


04  r  a  j 

a a  rt_4C^7_o&o_3u7_o*  r 

o  4  r  a  •• 

lNr»A_SfluP_co_3u7_A*r 

04T4 : 

( 0) _0UT_Pm7 

0474: 

ITin_NOMdN_ITEA_souw_fLiO  _jo  7_ss  7 

Q»Ta: 

mm  _£ 4f»  _7  tN  _0u 7  J> h  7 

0»  7a  : 

AM  _P  P  0  _7  c  N  _0(J  7  _3  A  7 

CiaTa: 

mm  wa  mn  _T  £  N  _0u  T  _p  M  T 

047a: 

P*cC_«P('._C£n_Q  JT_?P  7 

047a  : 

SE2_N0_JtjT_PPT 

047a  : 

70  7  _MM_;Ap_A*T3_PP7_7e.N_0u7_PM7 

0474 : 

707_MH_PMo_A*r3_PP  r _ r c.  *_30  7_,-M7 

0  4  7a: 

70  r  _|Mm_a*«v_a.«  T3_PPT_  7i.N_3u7_MM7 

047a: 

Oi:_CUS7_0U7_3AT 

04  7a: 

A«K_^Ea_aTA_C0_0o7_4A  7 

04  74 : 

7«_»I_3CO_Oo7_=97 

PIU£: 

•  0a«  _CtN_SO*»M_AWK-AorQ_SrlOi»_4S3_0>J  7_r*f  G 

CONTAINS 

t 

04  7a  : 

04  7E._aCmT_GN0..3UT_SnP 

o47»: 

I n  TP a_ SnOP,J3G_0u7<_SnP 

04  7  a  : 

ipj_oor_3nH 

0474  : 

I  TE.“_NOMfcN_I  TE  a_nou.N  _.rL0  _0U  7_S-P 

0*  7  4  : 

AM  ,s.f.r>  _7cN_OU7  _S«P 

04  7a  : 

AM  _pOg_7£N_OUT  _SmP 

0  a  7  A  : 

am  _4mn  _7En_0uT  _SmP 

04  7-  . 

po£C_«pk  _csn_o j r  _smm 

o  4  r  * . 

3£a«M0_u0  7_3mP 

04  7a. 

70  7  _am  _s.4p_4«  73_3mOP  _7t  n  _0U  7_3mM 

04  7a: 

70  7_mm _fH  j_a.»T3_3H0P_7Em_'jiJ  7_3mM 

04  7a; 

70  7  _am_amn_aaT  3_SmQP  _7£N  _jo  7  _SaM 

04  r  A : 

JIC_CU57_OU7^S->0 

047a: 

«PK_Pt3_STA_C0_0OT_»«P 

047a  : 

7M^Ai_oco_uur_5Mp 

r  [L£! 

•  Ohk 

„C  £  N  ..S  U «  *  _  <•  M  K  _  '  N  J  0  C  £  5  3  _A  3  M  u  7  _ '  p  0 

CO 

1 7 4 INS 

0474 : 

04  7E_4CP7_OkO_'JU7 

047a: 

FOL_«mK_C£n_ou  7 

04  7a: 

In7ka_SmoH_C3_3u7 

047a: 

£F3_0U7 

04  7a: 

I  7i-_N0rtN_;  7£A_AOUM_rL:)_jij7 

0  4  t  a  ; 

AM_tAM_l£N_Ju7 

0  4  T  a  : 

AM_0VE-(_i37_7rN_7u7 

04  Ta  : 

AM  _3M,j  _7 £ N_0U7 

04  7a; 

AM  _’4MM  _7EN,J0  7 

04  7a: 

3c  J_.NO  _3U  7 

04  7  a  : 

70  7_.mm_;.AM^;n_5mOP_7  £.a_o  J  i 

04  7  a  : 

70  7  _am  _Ov£  3  _£3  7  _7£m_  jo  7 

04  r  a  : 

70  7  _An  _mm  J  .'4_5mOP_7  iN  _3  j  7 

0  4  7a  : 

70  7_AH_-A!M_;N_SrlOP_ri'<_OJl 

04  7a  : 

J[C_CU37_3u7 

0  4  7a: 

70  _•  7_OCO_3U  7 

*ot  S"Y 

Oa  7a  : 

.«•* 

_C£N  _30MA_,AtAOE°  _AaO_Jo  7  :FO 

[NCLJOtS 

34  7a: 

34  rc_MOtM_jp(j_3u  7 

04  7a  : 

Ui:_SP7_0u7 

0  4  7a: 

ON  1 7  _AAa£_5M  7_3u  7 

Q4  7a: 

«M<  _C£n_CO_-Gu  7 

0  a  7  a  : 

•  OaK 

_C£n _Soma_7 A4ioE-,_«5o_3jr_;  tr  j 

;nCLjUcS 

j  a  r  4  ; 

73r.AA.:AF^iAK^C:.‘i*7£  *  _3  j  7 

j  a  r  a  : 

70  7  _“n  _-a  j  _.*<  _CiN_"  i.  a  _  '  j  7 

j  4  7  *•  i 

70  7  .An  .<••  .<nK  _  3  ^  ■  i.jj  f 

Figure  3-5  Hierarchical  Definition  of  the  Output  MESSAGE 
WORK  CENTER  SUMMARY  MSG  OUT 


A  problem  arises,  however,  in  properly  defining  the  processing  for 
the  output  description:  Equipment  Recall  Schedule,  as  shown  in  Figure  3-6. 
In  this  format,  a  multiple  listing  contains  several  end  items  of  eouipment 
being  recalled.  Because  of  its  multiple  nature,  these  items  would  normally 
be  CONTAINED  in  a  FILE.  For  each  such  end  item,  a  multiple  list  of  Work 
Order  numbers  (one  for  each  item  of  that  type  being  recalled)  exists  which 
includes  other  data  to  be  printed  along  with  each  Work  Order  Number  on 
multiple  lines.  This  also  would  normally  be  organized  as  a  FILE  which 
CONTAINS  all  the  OATA  items  to  be  printed  on  each  Work  Order  Number  line. 

A  problem  exists  because  the  formal  foundations  of  SREM  do  not  allow  a  FILE 
within  another  FILE,  as  is  suggested  by  the  FILE  of  work  order  information 
lines  within  each  instance  of  the  FILE  of  end  items  as  shown  by  the  format 
of  this  report.  To  handle  this  situation  unambiguously,  this  output  must 
be  treated  in  RSL  as  two  MESSAGES.  The  first  provides  the  one-time  pro¬ 
vision  of  header  data,  which  is  illustrated  in  Figure  3-7.  The  second 
MESSAGE  is  MADE  BY  the  two  DATA  items  for  the  part  number  and  the  end  item 
nomenclature,  plus  a  FILE  which  CONTAINS  multiple  sets  of  the  DATA  for  the 
Work  Order  Number,  the  item's  serial  number,  the  maintenance  code,  and  the 
equipment  location.  The  RSL  implementation  of  the  second  MESSAGE  is  shown 
in  Figure  3-8.  Table  3.4  compares  all  the  Annex  B  message  names  to  their 
RSL  equivalents. 


Fiyure  3-6  Format  for  the  Equipment  Recall  Schedule  Report 


AMXtil-06'S 


MESSAGE  £QuIP_R£CALL_SCHEDUL£_HEaDERwMSG_OuT. 

FORMED  sr  ALPHA  PR£P_£QP_RCL_SCH_HEAO£R_INFO_MSG. 
MAOt  ay 

DATA  0AT-E_3REP.0R0_22.4M 
DATA  UNIT_NAmE_SPT_22_AM 
DATA  UIC_S3T _22_>M 
DATA  UNIT_MAME_CUST_22_AM 
DATA  UIC_CJST_22_4M  . 

Equated  to  synonym  02_22_am. 


Figure  3-7  Hierarchical  Definition  of  the  Output  MESSAGE: 
EQUIP  RECALL  SCHEDULE_HEADER_MSG_OUT 


MESSAGE  EQUIP_R£CALL_SCHEQUL£_MSG_0UT. 

Formed  dY  alpha  PR£P_£QP_RCI _ 3C<h_22_>,m_mSG. 

MADE  3Y  DATA  3H  T_N0_F uD_22_AM 

DATA  I  TEM_NOMEN_I  TE.M.N0UN _FLD_22_aM 

file  equip_recall_sch_out. 

EQUATED  TO  SYNONYM  02_22AJ»M. 

file  equip_pecal! _ scH_our. 

CONTA INS 

DATA  EQUIP_5Eh_lCL— C0N_N0_FL0_22_am 

DATA  RQR  WMA  InT_C0_22_AM 

DATA  MA  I  NT_SCO_SVC  J)AT£_0R0_22.4M 

DATA  EQUIP  _L0C_2  2_*M 

DATA  wPK_Q DH _N0_22_AM. 


Figure  3-8  Hierarchical  Definition  of  the  Output  MESSAGE: 
EQUIP_RECALL_SCHEDULE_MSG_OUT 
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Table  3.4  Comparison  of  Annex  B  Output  Description  and  Equivalent  RSL 
MESSAGE  names  (Continued) 


wop  stocx  2M  uuia  R£Porr 


shop  stocx  ujcato*  umao 


SHOP  STT3CX  C3HSTJUINT  UPOPT 


1f*Qt  STOCX  .1ST 


«ow  scares  ^rsowcl  ^asrsa 


U»MP  jfTLi^rTGH  3CTACI 


jwa  wr*  supyct 


iua  aa?rw  i.^t 


shop  jroac  jj  st.xm  jpumce  jcwpt_ 

?£P9rrj€A0C*  JSS  JUT 

wop  jnoac  j.  rrrjsw  jauwccjcpopt. 

tS5  OUT 


WOP  STOCX  J.ST 

.  ]2  3  W  , 

:2_:i  m 

wop  stocx  ,:rr  -caoep  '•sc  jut 

i  j 

4(M 

32  39  4* 

WOP  STOCX  -.ST  *5G  CUT 

«jojp_  |  wop_rroo^oaro«-xrn«i6j£«oj«fijjuT 


|  3tJOJ*  | 


32  41  *  AT  32  4>  *T  :i 


wop  j roa  J.CCA  to*  j.  :st  jsg  jut 


wop  jroa  jcsmrap  mt  jpt  ju*j«  jut 

SHOP  JTOCX  JSWT3U  «T  JPTJUpQS  J^G  JUT 


i€KH  JTOCX..IST  j€A0M  JSGJUT 

io»cn  rrccx  .;rr  *sg  xrr 


wwoa  onu^noN  iwwT 

32  5Q  Ay 

32_S0X-4T  1 

.MOP  JTIU2WI0N  JUW1PY  ^UOCP  J5G  JUT 

1 

1 

32J01-4T  , 

.mop  jjhuzah  a*  jamun  _*•*  jv*  i  l  jsojut 

32  J 0C-4T  j 

■ 

32J00JY  ; 

■-M^u^Tiop^sipwuiY^airrj^jwcLjso  jut 

y  1 

32  JQl  *Y 

I  .mop  'jnu»no*  wit  j*  *sc  out 

22  W  44  KJO  J*  jwver  JX  JUT 


32  11  J*  :  32  4!  4*  ;SM£  SXCO»TTOB  .;ST  *SG  3UT 


4MK  3P0CR  2ATA 

,  32  30  iW  i 

!  j 

32JOJ«Jj 
32jo  jw_ 

:i 

j  4}pkjrom 

-opkjpocp 

jat»  jascjsojur 

jmjun  jig  jur 

:zjo  w 

'  *0»K  3P0M 

3ATA  3SGIST7Ar::>l  -SG  Cut 

JjWSfill  SATA 

32  22  2U 

12  J2A  JW 

<F*ej3UlPJ6CAU_'W  J”^.  >■€  JJ5GJUT 

22  J2IMU 

: F?R  jcu l ?  JCCAX.U  Jft  _  T71JM?  J_«SG  JUT 

12J2CJW  1 

(F»2  j.c*rj?ujaaiST^MT.*sG_:uT 

2ZJ20JU 

<f*r  jn  _^mr  jsg  jut 

HJttJW 

12  J2FJN  1 

<F*P  JiSX  JW  J4CT3P  J0JUST*C1TJS6_?UT 

2ZJ2GJM  ‘ 

:  ft*  _  JSAC*  JEY  t  CE  _ !  WWOT  _  WMSt  J5G  JUT 

:2  ja  w 

t  F*s  j  SMC  _!A  TA  JSG  JU  T 

12.22:  JM 

•  JPOSS  JCF  .  ■  «I  J  .430  JSS  _1UT 

•  2  J2J  W 

FT3  ipossjcf.  -TJJAUOJSG jut 

Table  3.4  Comparison  of  Annex  3  Output  Description  and  Eauivalent  RSL 
MESSAGE  names  (Continued) 


urn  umu  i 

ISI 

yumsT  -mi 

:3  ;oo£ 

SYNONVM 

)UWT  'CSSMt  'TTU 

a#*i_r  acntiTT 

22  43  JO 

32J3  JO— 
AO 

ajnjo_ 

An 

si#  *cr  «3ptts  v  w  j<q  liM  :n  -so  dot 

si#  _*ct  j&trs  jmjsrs  jaui  jw  is  jso  jut 

«a»ciLL»nQ»  acEPrron  »£««t 

32  39  ** 

»  jsjuj 

:i 

KJSJ*. 

u: 

Aca«CL_acr*^_jfT-rrAT.#0ATc--9S_3UT 

W2K11  HOI  ▼  V?  3*  OUT  •«  **  A  MSfi  3UT 

ascii  jxcjp  r  jvrjui  js  jo  jccosojkjut 

a#*.r  actwty  *njur*M»rs 

32  M  «J 

32 

22_36*-*0 

32  JSC  JO 

«#p  4cnvj®rnjn. j*ra  josjur 

sirnr  jcttv  rn  jo*n  _:A*ai  jou#  jjooot 
su*p  jcnv  jams  jou#  joow  .our 

(WSOUTTVf  EOUlP«ll»T  STATUS  2ATA 

_ 

32  9.30 

32J9SJO 

:2  JM  JO 

:  m#  jou  f  ?  JTa  rus  _3ata  jcs :  srw  r  on  j*sg  jut 

:  w  JOU  I  P  JTMTB  _3ATA  JASTS  jCfiJUT 

3.4  DEVELOPMENT  OF  GLOBAL  DATA 


There  are  two  categories  of  DATA  in  RSL:  LOCAL  and  GLOBAL. 

Data  which  is  LOCAL  is  associated  only  with  the  R_NET  in  which  initialized 
or  in  which  introduced  (by  an  input  MESSAGE  or  the  OUTPUT  FROM  an  ALPHA) 
and  is  not  accessible  to  any  other  R_NET.  It  exists  only  until  processing 
in  that  R_N£T  is  complete.  For  example,  if  there  is  a  DATA  item  called  X 
which  is  LOCAL  to  an  R_NET,  each  time  that  the  R_NET  is  traversed,  X  will 
have  a  value,  but  each  time  the  value  may  be  different,  and  only  the  cur¬ 
rent  value  of  X  is  available  for  any  given  traversal .  GLOBAL  OATA,  on  the 
other  hand,  is  permanent  and  can  be  accessed  by  any  R_NET  any  time  it  is 
traversed. 

The  concept  ENTITY  is  used  as  a  means  of  organizing  the  global  data 
in  REVS.  An  ENTITY_CLASS  is  a  repetitive  data  set  which  is  meant  to  cor¬ 
respond  to  some  real  object  or  conceptual  entity  which  is  of  concern  to  the 
DP,  and  an  ENTITY_TYP£  is  a  sub-classification  within  an  ENTITY_CLASS.  An 
£NTITY_CLASS  is  COMPOSED  OF  ENTITY_TYPEs .  ENTITY_CLASSes  and  ENTITY_TYPEs 
have  GLOBAL  DATA  and  FILES  ASSOCIATED  WITH  them.  DATA  or  FILES  which  are 
common  to  all  the  ENTITY_TYPEs  in  the  ENTITY_CLASS  are  ASSOCIATED  WITH  the 
ENTITY  _CLASS,  and  each  ENTITY_TYPE  in  the  ENTITY_CLASS  can  have  different 
DATA  or  FILEs  ASSOCIATED  WITH  it.  An  ENTITY_CLASS  or  ENTITY_TYPE  usually 
possesses  several  instances  of  the  set  of  DATA  and  FILEs  ASSOCIATED  with 
it.  The  definitions  for  RSL  elements  and  relationships  which  apply  in 
developing  the  GLOBAL  data  for  the  MOMs  DFSR  are  given  in  Table  3.5,  and 
their  interrel ationships  are  illustrated  in  Figure  3-9. 

Some  GLOBAL  DATA  or  FILEs  are  not  associated  with  an  ENTITY_CLASS  or 
ENTITY_TYPE  because  there  is  never  more  than  one  instance  of  them  main¬ 
tained  GLOBALLY  in  memory.  These  may  be  GL08AL  flags,  GLOBAL  lists,  GLOBAL 
constants,  or  any  other  DATA  items  whose  values  change  from  time  to  time, 
but  for  which  no  more  than  one  value  is  ever  resident  at  one  time.  In  the 
MOMs  DFSR,  an  example  is  CURRENTJDATE  which  is  used  as  the  source  of  infor¬ 
mation  for  transfer  as  OATA  being  stored  in  an  ENTITY_CLASS  or  ENTITY_TYPE 
during  certain  processing. 

The  ENTITY_CLASSes  and  ENTITY_TYPEs  were  developed  orimarily  from 
Annex  D  of  the  MOM  DFSR.  Each  data  base  descriDtion  in  Annex  0  was  treated 
as  an  ENTITY_CLASS  with  at  least  one  ENTITY_TYPE  being  assigned  to  each. 
SYNONYMs  were  assigned  to  each  ENTITY_CLASS,  using  the  File  ID  from  the 
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Table  3.5  RSL  Definitions  Used  in  the  Development  of  ENTITY_CLASSes  and 
ENTITY  TYPES 


DEFINITION  OF  ELEMENTS 

ENTITY  _CUSS 

A  GENERAL  CATEGORY  OF  OBJECTS  OUTSIDE  THE  DATA  PROCESSING 
SUBSYSTEM.  THE  08JECT  ARE  THOSE  IN  THE  ENVIRONMENT  ABOUT 
'WHICH  THE  DATA  PROCESSING  SUBSYSTEM  MUST  MAINTAIN  INFORMATION. 

£NTITY_TYPE 

A  SUBSET  WITHIN  A  GENERAL  CLASS  (ENTITY.CLASS )  OF  OBJECTS 

OUTSIDE  THE  QATA  PROCESSING  SUBSYSTEM  ABOUT  ^HICH  THE  DATA 
PROCESSOR  MUST  MAINTAIN  INFORMATION. 

FILE 

AN  AGGREGATION  OF  INSTANCES  OF  OATA,  EACH  INSTANCE  OF  WHICH 

IS  TREATED  IN  THE  SAME  MANNER. 

DATA 

A  SINGLE  PIECE  OF  INFORMATION  OR  SET  OF  INFORMATION  REQUIRED 

IN  THE  IMPLEMENTED  SOFTWARE. 

DEFINITION  OF  RELATIONSHIPS 

COMPOSES 
(COMPOSED  OF) 

IDENTIFIES  TO  WHICH  £NTITY_CLASS  AN  ENTITY_TYPE  BELONGS. 

ASSOCIATES 
(ASSOCIATED  WITH) 

IDENTIFIES  WHICH  OATA  ANO  FILES  COME  INTO  EXISTENCE  WHEN  A 

OATA  PROCESSING  STEP  (AN  ALPHA)  EITHER  CREATES  AN  INSTANCE 

OF  AN  ENTITY  CLASS  OR  SETS  THE  ENTITY  TYPE  OF  an  INSTANCE  OF 

AN  ENTITY_CLASS. 

CONTAINS 
(CONTAINED  IN) 

IDENTIFIES  THE  MEM8ERS  OF  EACH  INSTANCE  IN  A  FILE.  OATA  MAY 

BE  CONTAINED  IN  ONLY  ONE  FILE. 

INCLUDES 
(INCLUDED  IN) 

I NO I CATES  A  HIERARCHICAL  RELATIONSHIP  BETWEEN  OATA;  ~HAT  IS 

OATA  INCLUDES  DATA. 

-  CONTAINS  - •» 

CONTAINED  IN  - 


Figure  3-9  GLOBAL  DATA  and  FILE  Interrel ationshios 
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equivalent  file  description  in  Annex  0.  Table  3.6  provides  a  comparison  of 
the  files  in  Annex  D  and  RSL  equivalent  ENTITY_CLASSes.  An  example  of  a 
completely  defined  ENTITY_CLASS  from  the  requirements  data  base  is  shown  in 
Figure  3-10. 

An  instance  of  an  ENTITY_CLASS  is  equivalent  to  a  record  in  a  file  of 
Annex  D.  A  new  instance  of  an  ENTITY_CLA$S  (a  record)  is  CREATED  BY  an 
ALPHA  in  an  R_NET,  and  the  data  stored  in  the  new  instance  of  the  ENTITY_ 
CLASS  is  typically  provided  by  one  of  the  input  MESSAGES  described  as 
real-time  processing  (e.g.,  XMA,  XMB ,  etc.). 

A  particular  instance  of  an  existing  ENTITY_CLASS  or  ENTITY_TYPE  may 
be  SELECTed  in  an  R_NET  or  SUBNET  such  that  a  certain  boolean  condition 
exists.  An  example  of  the  use  of  the  SELECT  node  is  shown  in  Figure  3-1 la. 
Once  selected,  all  the  OATA  and  FILE  information  ASSOCIATED  with  the  selec¬ 
ted  ENTITYJCLASS  or  ENTITY_TYPE  remains  available  until  another  instance  of 
the  same  ENTITYJCLASS  or  ENTITY_TYPE  is  selected,  or  the  processing  on  the 
R_NET  on  which  SELECTed  is  completed. 

A  sequence  of  SELECTS  can  be  defined  in  an  R_NET  or  SUBNET  by  using 
the  FOR  EACH  node.  This  may  be  non-conditional,  as  shown  in  Figure  3-llb, 
which  means  that  all  instances  of  the  defined  repetitive  set  (an  ENTITY_ 

CLASS,  an  ENTITY_TYPE,  or  a  FILE)  are  each  selected  in  turn  and  subjected 
to  the  processing  described  by  the  ALPHA  or  SUBNET  which  follows  the  FOR 
EACH  node  (the  ALPHA  and  SUBNET  are  the  only  legal  nodes  that  can  follow  a 
FOR  EACH).  The  FOR  EACH  may  also  be  conditionally  constrained,  as  illus¬ 
trated  in  Figure  3-llc.  In  such  a  case,  only  the  members  of  the  repetitive 
set  for  which  the  conditional  statement  is  true  are  selected  in  turn  for 
the  indicated  processing  of  the  following  ALPHA  or  SUBNET. 

Finally,  at  some  point  in  the  processing,  ENTITY_CLASS  instances  will 
typically  no  longer  be  needed  and  should  be  purged.  This  is  accomplished 
by  selecting  the  appropriate  instance  of  the  ENT!TY_CLASS  which  can  then  be 
DESTROYED  BY  an  ALPHA. 
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Table  3.6  Companion  of  Annex  D  Files  and  Equivalent  RSL  ENTITYCLASSes 
and  ENTITY  TYPES 


PAMAMEltR  MUKklOAO  BACKLOG  AGt  XM/  C  UAHS 


Table  3.6  Comparison  of  Annex  0  Files  and  Equivalent  RSL  ENTITYCLASSes 
and  ENTITY  TYPES  (Continued) 


t-po-tsxiw 


EnTITy  _ CLASS :  CR0SS_R£FER£NC£_F I l£ 

EQUATED  TO 

SYNONYM:  F2_01_8P_XREF 

DOCUMENTED  BY 

SOURCE:  APP_D_ 3 AG£_Q2 

COMPOSED  OF 

ENTIT Y_TYP£ :  MANEU V£R—CUSTQM£R_8_CARD 
ASSOCIATES 

OaTa:  MNVR_CUST_CR_REF_INFO 

INCLUDES 

DATA:  AAC_CUST_CRF_8 

DATA:  ACCT_PR0C_FLD_CUST_CRF_8 

OATA:  CARO  J3SG_CD_SAMS_.CRF._d 

OATA:  COMO  JDSG_NSTR_REC_CRF_B 

OATA:  CQMQJ3SG  _8EIMd_CUST  jCRF_3 

OATA:  Ul C_CUST  _CRF_d 

OATA.  UIC_PRNT  JJN I T_CUST _CRF_B 
OATA:  UNIT_NAME_CUST_CRF_8 

OATA:  JNITj<AME_PRNT_CUSr_CRF_3 

ENT  I T Y_TYP£ :  SUPPORT_UNlT_A_CARQ 
ASSOCIATES 

DATA:  SP  T_UN IT_CH_R£F_I nFO 

INCLUOES 

DATA:  AAC_SPT_CRF_A 

OATA:  ACCT  _P RO C_F L D_ SP  T_CRF_A 

OATA:  CARO_DSG_CQ_SAMb  _CRF_a 

OATA:  CQNO  J3SG_RElMd_CUST_CRF_A 

OATA:  UiC_PRNT_UN  I T_5PT  CRF_A 

DATA:  UIC_SPT_InOIC_CRF_a 

OATA:  UNIT_NAME_PRNr_SPT_CHF_A 

OATA:  UNIT_NAME_SPT_CRF  A 

ASSOCIATES 

OATA  :  -IOR_DATA_ELEmEnTS_CR  JREF_InF  0 


INCL JOES 

DATA  : 

cono_dsg_rept_rqmt_crf 

OaTa  : 

F  Il£_IDEnT_NO_CD _CHF 

OaTa  : 

inq_act_cd _chf 

0  A  T  A  : 

NORM_«RK_PO_TEV_CRF 

DATA : 

PCN_CHF 

OaTa  : 

PREV  _DAY_CYC_DATE_CWF 

QA  T  A : 

PR£v_mO_CYC_DA  IE_CHF 

OATA  : 

PR  E V  _•<£. T_CY C_3 A  TE.CRF 

DATA: 

R£3_£NO  J3ATE_ORD_CRF 

QaTa: 

R£3_ST  ART_DA TE _ORO_C RF 

a  :  jIC_ 

5P  T_CRF 

INCLJOES 

OATA : 

0£ SCR  I PT I VE_D£ 5 I 3_CR F 

OATA: 

PRnT_ORG_OESIG  _CRF 

DATA : 

SVC  J3E5IG_CRF 

Figure  3-10  Hierarchical  Definition  of  the  ENTITY_CLASS 
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gure  3-11  Examples  of  a  SELECT  and  FOR  EACH  Node 


3.5  DEVELOPMENT  OF  REQUIREMENTS  NETS  (R_NET) 

Once  the  interfaces,  and  MESSAGES  that  cross  these  interfaces,  were 
identified,  analysis  of  the  processing  stimulated  by  the  receipt  of  the 
input  MESSAGES  was  initiated  and  documented  by  development  of  R_NET  and 
SUBNET  structures.  Definition  of  the  elements  and  relationships  used  in 
development  of  R_NETs  is  shown  in  Table  3.7.  The  inter-relationships  of 
these  items  is  provided  in  Figure  3-12. 

3.5.1  R  NET  Considerations 

Functionally,  the  R_NETs  describe  the  processing  steps  (ALPHAs)  which 
must  be  performed  as  a  result  of  the  arrival  of  each  input  MESSAGE,  the 
sequence  of  the  ALPHAS,  the  logical  process  branching,  and  the  output 
MESSAGES  which  the  data  processer  is  required  to  produce. 

The  R_NET  resembles  a  traditional  flow  chart  in  appearance  and  repre¬ 
sents  the  processing  required  in  response  to  each  possible  stimulus.  This 
stimulus  may  be  either  of  two  types  —  the  arrival  of  a  MESSAGE  from 
another  SUBSYSTEM  at  the  INPUT_INTERFACE  on  the  R_NET,  or  the  occurrence  of 
some  EVENT.  In  the  former  case,  the  R_NET  is  said  to  be  ENABLED  by  the 
INPUT_INTERFACE  and  this  interface  appears  as  the  first  node  on  the  R_NET 
structure.  In  the  latter  case,  the  R_NET  is  ENABLED  by  the  EVENT,  which 
itself  appears  as  a  node  on  some  R  NET  or  SUBNET  (or  on  more  than  one  such 
structure)  in  the  system.  The  interpretation  is  that  the  subject  R_NET  is 
ENABLED  whenever  control  reaches  the  EVENT  node  on  the  R_NET  or  SUBNET  on 
which  the  EVENT  appears. 

An  ALPHA  is  a  processing  step  which  possesses  a  single  entry  and  exit 
path.  The  ALPHA  processes  DATA  and  FILE  information  which  is  INPUT  TO  it, 
accomplishes  the  appropriate  DATA  transformations ,  and  OUTPUTS  the  result¬ 
ing  DATA  and  FILE  information  for  GLOBAL  storage,  for  use  in  subseauent 
branching  logic,  for  use  in  following  ALPHAs  or  for  producing  an  output 
MESSAGE.  An  ALPHA  may  also  describe  other  processing.  For  example,  an 
ALPHA  can: 

•  FORM  an  output  MESSAGE. 

•  CREATE  a  new  instance  of  an  ENTITY  CLASS. 
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Table  3.7  RSL  Definitions  Used  in  the  Development  of  R  METS 


DEFINITION  OF  ELEMENTS 

R_NET 

A  STRUCTURED  'SRAPH  OF  LOGICAL  PROCESSING  STEPS  HAT  MUST  3E 

PERFORMED  3Y  HE  OATA  PROCESSING  SUBSYSTEM  IN  RESPONSE  *0 

EXTERNAL  OR  INTERNAL  STIMULI.  HE  PROCESSING  STEPS  ARE  ALPHAS 

OR  SUBNETS  WHICH  MAY  3E  EXPANOED  TO  LOWER  LEVELS  QF  DETAIL. 

SUBNET 

A  SUBSTRUCTURE  OF  LOGICAL  PROCESSING  STEPS  HAT  MUST  3E  PER¬ 
FORMED  TO  ACCOMPLISH  HE  REQUIREMENTS  OF  HE  NEXT  HIGHER 

NETWORK  (SU8NET  OR  RJYET)  ON  WHICH  HE  SUBNET  IS  REFERENCED. 

ALPHA 

A  SASIC  PROCESSING  STEP  IN  HE  FUNCTIONAL  REQUIREMENTS. 

a(TITY_CUSS 

A  GENERAL  CATEGORY  OF  OBJECTS  OUTSIDE  HE  OATA  PROCESSING 

SUBSYSTEM.  HE  OBJECT  ARE  HOSE  IN  HE  ENVIRONMENT  A80UT 

WHICH  HE  OATA  PROCESSING  SUBSYSTEM  .MUST  MAINTAIN  INFORMATION. 

ENTITY  JYPE 

A  SUBSET  WITHIN  A  GENERAL  CLASS  (ENTITY_CLASS )  OF  OBJECTS 

OUTSIDE  HE  OATA  PROCESSING  SUBSYSTEM  ABOUT  WHICH  HE  OATA 

PROCESSOR  MUST  .MAINTAIN  INFORMATION. 

MESSAGE 

AN  AGGREGATION  OF  OATA  ANO  FILES  HAT  PASS  HROUGH  AN  INTER¬ 
FACE  AS- A  LOGICAL  UNIT. 

FILE 

AN  AGGREGATION  OF  INSTANCES  OF  OATA,  EACH  INSTANCE  OF  *HICH 

IS  TREATED  IN  HE  SAME  MANNER. 

DATA 

A  SINGLE  PIECE  OF  INFORMATION  OR  SET  OF  INFORMATION  REQUIRED 

IN  HE  IMPLEMENTED  SOFTWARE. 

DEFINITION  OF  RELATIONSHIPS 

CREATES 
(CREATED  3Y ) 

INDICATES  HAT  HE  ALPHA  CREATES  AN  INSTANCE  OF  HE  ENTITY JC LASS. 

_ 

QESTROYS 
(DESTROYED  BY) 

I NO I CATES  HAT  HE  ALPHA  OESTROYS  HE  CURRENTLY  SELECTED  INSTANCE 

OF  HE  £NTITY_CLASS. 

j  FORMS 

(FORMED  3Y ) 

INDICATES  HAT  HE  ALPHA  ESTABLISHES  HE  "ESSAGc  AS  HE  ONE  '0  3E 

1  PASSED  3Y  HE  CORRESPONDING  OUTPUT  INTERFACE  WHEN  HAT  INTERFACE 

1  IS  ENCOUNTERED  ON  HE  YET 

INPUTS  i  IDENTIFIES  HE  CATA  ANO  -ILES  USED  3Y  HE  ALPHA. 

(INPUT  TO)  | 

!  OUTPUTS  1  IDENTIFIES  HE  OATA  ANO  "LEE  -.HOSE  ! ALUE3  OR  CONTENTS  ARE  MOOIFIED 

1  (OUTPUT  -ROM)  j  3Y  HE  ALPHA. 

i  errs  inoicatss  hat  he  alpha  estaslcshes  he  currently  selected  instance 

I  StT  3Y )  !  OF  an  ENTITY  CLASS  -0  S£  OF  HE  ENTIT'_-'PE. 


t  CONTAINS  IDENTIFIES  HE  MEMBERS  OF  EACH  INSTANCE  IN  A  FILE.  OATA  '*AY  3£ 

|  CONTAINED  IN)  j  CONTAINED  IN  ONLY  ONE  "L£. 

I  INCLUDES  INDICATES  A  HIERARCHICAL  RELATIONSHIP  3E“wESN  CATA,  HAT  IS  CATA 

INCLUDED  IN)  INCLUDES  OATA. 

i _  _ _ 

I  REFERS  1  INDICATES  ELEMENT  "'=ES  HAT  -RE  IN  HE  CTR'JCHRE  IF  ;  RJ£-  IR 

!  REFERRED  3Y’  ,  SU3NET . 
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•  SET  a  transformation  of  an  ENTITY_TYPE  from  one  type  to 
another. 

•  DESTROY  an  instance  of  an  ENTITY_CLASS  (to  include  its 
COMPOSED  ENTITY_TYPE). 

As  subsequent  analysis  of  processing  continues,  it  may  be  determined 
that  some  logical  branching  is  appropriate  wi thi n  the  ALPHA  such  that  more 
than  one  output  path  could  occur.  In  such  a  case,  it  should  be  replaced  by 
a  SUBNET  which  can  contain  processing  logic.  The  SUBNET  is  treated  as 
though  the  flow  path(s)  in  the  SUBNET  were  physically  inserted  into  the 
higher  level  flow  path  of  the  structure  on  which  it  is  located. 

More  complex  flow  situations  are  expressible  in  RSL  by  the  use  of 
structured  nodes  which  fan-in  and  fan-out  to  specify  different  processing 
paths.  The  structured  nodes  are  the  AND  and  OR  nodes. 

The  meaning  of  an  AND  structure  is  that  the  paths  are  mutually  order- 
independent.  The  processes  or  parallel  paths  may  be  executed  in  any  order, 
or  even  in  parallel.  The  fan-in  at  the  end  of  the  AND  structure  is  a 
synchronization  point.  All  of  the  parallel  paths  must  be  completed  before 
any  of  the  processes  following  the  rejoin  are  performed.  There  are  two 
types  of  OR  nodes:  the  basic  OR  node  and  the  CONSIDER  OR  node.  For  the 
basic  OR  node,  the  condition  on  each  exit  of  the  node  is  a  standard  Boolean 
expression  which  may  involve  DATA  elements  and  constants.  This  condition 
is  evaluated  when  the  OR  node  is  reached.  The  first  condition  to  be  eval¬ 
uated  as  TRUE  specifies  the  exit  branch  to  be  followed.  To  Drevent  pro¬ 
blems  if  all  specified  conditions  are  FALSE,  an  OTHERWISE  declaration  is 
used  to  specify  a  branch  to  be  followed  in  such  a  case.  Thus,  a  basic  OR 
node  must  have  one  branch  with  an  OTHERWISE  declaration.  The  basic  OR  node 
is  illustrated  in  Figure  13a. 

The  CONSIDER  OR  node  allows  branching  on  the  value  of  DATA  which  is 
of  TYPE  ENUMERATION,  or  branching  on  the  ENTITY_TYPE  of  the  currently 
SELECTed  ENTITY_CLASS.  Each  branch  of  the  CONSIDER  OR  has  an  associated 
criterion.  DATA  with  TYPE  ENUMERATION  have  values  which  are  expressed  as 
words.  The  criteria  specify  which  branch  is  to  be  taken,  based  on  the 
value  of  the  enumerated  DATA  item  under  consideration.  All  of  the  legal 
value  names  must  appear  once  and  only  once  in  the  branching  criteria. 

Since  the  criteria  for  a  CONSIDER  OR  must  be  exhaustive,  an  OTHERWISE 
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FILE  INPT  ACT.  CO  IN 


INTERPRETATION:  IF  THE  TWO 
INDICATED- DATA  ELEMENTS  HAVE 
THE  SAME  VALUE.  CONTINUE 
PROCESSING  DOWN  BRANCH  Q. 
OTHERWISE,  CONTINUE  PROCESSING 
DOWN  BRANCH  (T). 


INTERPRETATION:  CONSIDER  THE  VALUE 

orrur  tudtcateo  oataelemenl  if  its 

VALUE  IS  A.  PROCESS  BRANCH  ©. 

OR  IF  ITS  VALUE  IS  8.  PROCESS  BRANCH 
OR  IF  ITS  VALUE  IS  0,  PROCESS  BRANCH 


A:  A  BASIC  OR  NOOE 


3:  A  CONSIDER  OR  NOOE 


Figure  3-13  The  Two  Kinds  of  OR  Nodes 

branch  is  not  allowed.  An  example  of  a  CONSIDERJDR  is  shown  in  Figure 
3- 1 3b . 

Figure  3-14.  shows  the  R_MET,  SUBNET  symbology  used  for  SREM  structure 
development.  All  but  the  final  symbol,  the  VALIDATION_POINT,  were  used  in 
the  MOM  OFSR  effort.  The  VALIDATION_POINT  would  be  used  in  Phase  6  of  SREM 
which  was  beyond  the  scope  of  this  effort. 

3.5.2  Example  of  an  R  NET  Development 

R_NETs  are  developed  in  a  top  down  fashion,  and  any  SUBNET  defined  on 
the  R_NET  (or,  for  that  matter,  on  a  SUBNET)  is,  itself,  subjected  to 
definition  of  the  logic  of  processing  it  represents.  For  example,  the 
R_NET:  PROCESS_MOM_KEYBOARD_INPyT,  Figure  3-15  defines  the  Drocess'no  ffrr 
all  input  MESSAGES  passing  the  INPUT_INTERFACE :  FROM  vpf*  KEYBOARD.  Note 
that  the  first  branch  decision  is  accomplished  by  determining  *he  *y’~» 
MESSAGE  received  through  the  INPUT  INTERFACE,  "he  process-'na  :»  T'.* 
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ALPHA 

AND 

© 

ENTRY  NODE  ON  R_NET 

ENTRY  NODE  ON  SUBNET 

V 

EVENT 

© 

FOR  EACH 

© 

INPUTJNTERFACE 

o 

IF  OR  - 

© 

CONSIDER  OR 

aT 

OUTPUT  ^INTERFACE 

(  ) 

SELECT 

© 

SUBNET 

O 

RETURN 

A 

|  TERMINATE 

1 

A 

|  VALIDATION  JOINT 

© 

Figure  3-1 4  R_NET,  SUBNET  Symbology 
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Figure  3-15  RNET:  PROCESS_MOM_KEYBOARD_INPUT  (NET  RT1000) 

MESSAGE  is  defined  on  a  separate  processing  path  by  a  SUBNET  which  contains 
the  processing  intended  on  that  branch.  The  decision  on  which  processing 
path  to  be  taken  is  based  on  the  value  of  DATA:  MOM_KYBD_MSG  TYPE  which  is 
of  TYPE  ENUMERATION.  Thus,  the  OR  node  is  a  CONSIDER  OR. 


3.5.3  Definition  of  SUBNET  Processing 

Each  SU8NET  is  further  defined  separately.  The  SU8NET :  PERFORMANCE_ 
ST0RE_TEMP_INF0  (not  shown)  is  a  complex  SUBNET  which  branches  to  indivi¬ 
dual  processing  paths,  depending  on  the  value  of  the  DATA  item:  DIC  (e.g., 
XMA,  XMB,  etc.).  For  example,  one  branch  for  XMA  contains  the  SUBNET: 


PROC£SS_XMA_ENTRY.  This  SUBNET  is  shown  in  Figure  3-16  and  is  a  summary 
net,  in  that  it  is  defined  as  three  other  SUBNETS.  Note  that  two  of  the 
SUBNETS  have  SYNONYMs  shown  (e.g.,  A1001,  and  A1008).  The  third  SUBNET  is 
indicated  as  undefined.  This  is  because  no  processing  logic  was  described 
for  the  legal  condition  where  the  value  of  the  DATA  item  FILE_INPT_ACT_ 
CD_IN  was  0.  This  is  an  example  of  incomplete  logic  documented  in  a 
Trouble  Report  as  a  deficiency. 


V 


FILE  INPT  ACT  CD  IN 


Figure  3-16  SUBNET:  PROCESS_XMA_ENTRY  (NET  A1000) 

We  can  illustrate  one  level  lower  by  reviewing  the  definition  of 
SUBNET:  PR0CESS_XMA_A.  This  SUBNET  which  is  shown  in  Figure  3-17,  pro¬ 
vides  the  first  look  at  processing  at  the  ALPHA  level.  In  this  process, 
the  first  node  (at  )  indicates  that  a  particular  instance  of  GLOBAL 
information  is  selected  from  the  ENTITY_TYPE:  SUPPORT_UNIT_A_CARD  for  use 
in  the  processing  that  is  to  follow.  At  a  decision  is  made  as  to  what 
processing  should  occur  if  the  selected  instance  is  not  found  (this  is  an 
important  consideration  which  defines  a  possible  error  path  that  typically 
is  not  covered  in  most  software  specifications  ...  and  wasn't  in  the  MOM 
OFSR).  The  term  "(FOUND)"  is  the  name  of  a  DATA  item  that  is  of  TYPE 
BOOLEAN  and  which  has  a  VALUE  of  TRUE  or  FALSE  term.  At  this  Doint,  the 
"OTHERWISE"  indicates  the  branch  to  be  taken  if  the  VALUE  of  FOUND  is 
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Figure  3-17  SUBNET:  PROCESS_XMA_A  (NET  A1001) 

FALSE.  In  this  case,  the  processing  (at  prepares  to  produce  an  output 
error  MESSAGE  (which  is  actually  produced  in  the  SUBNET:  SEND_PROCESS_ 
ERROR_MSG.  Process1' ng  is  then  terminated  on  this  branch  for  the  current 
stimulus. 

If  the  selected  ENTITY_CLASS  is  found,  the  UIC_SPT  and  SEQ_NO  values 
found  in  the  input  MESSAGE  are  stored  (^^)  as  GLOBAL  DATA  in  a  new  in¬ 
stance  of  the  ENTITY_CLASS:  WORK_OROER_REGISTRATION_FILE_WORF.  There¬ 
fore,  the  ALPHA:  STOREJJIC  SPT_NR_AND_SEQ_NR  also  CREATES  this  new  instance 
of  the  ENTITY_CLASS.  Next,  (at  (F))  the  instance  of  tne  ENTITY_TVPE: 
MANEUVER_CUSTOMER_B_CARD  is  selected  which  possesses  the  same  UIC_SPT  and 
UIC_CUST  code  as  those  1-n  the  input  MESSAGE.  In  this  case,  the  decision  as 
to  whether  or  not  the  information  was  found  was  accomplished  at  (F)  inside 
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the  SUBNET:  CHECK_UIC_AGAINST_XREF.  The  processing  in  this  SUBNET  (not 
shown)  indicates  that  if  the  information  is  not  found,  an  informative 
message  is  transmitted;  otherwise  none  is  transmitted.  In  either  case, 
UIC_CUST_IN  is  stored  (^^)  as  UIC_CUST_WORF  in  the  same  instance  of  the 
ENTITY_CLASS:  W0RK_0R0ER-REGI STRATI QN_F I LE_W0RF  that  was  CREATED  in  the 
preceding  ALPHA. 

Following  this  step,  the  final  process  is  provided  by  SUBNET: 
PR0CES5_JNTRA_SH0P_CD,  which  assigns  the  appropriate  letter  value  for  DATA: 
INTRA_SH0P_C0.  With  the  completion  of  this  SUBNET,  processing  is  complete 
for  the  stimulus  that  intiated  processing.  Thus,  the  R_NET  unambiguously 
defines  all  the  possible  paths  of  processing  that  could  occur  as  a  result 
of  the  receipt  of  a  particular  input  MESSAGE,  in  this  case,  XMA  input 
information  where  F I L E_I NPT_ACT_C D_I N  had  a  value  of  A. 

3.5.4  Reason  for  Liberal  Use  Of  SU8N£Ts 

The  reader  may  be  wondering  about  the  considerable  use  of  SUBNETS  in 
the  definition  of  processing.  The  reason  for  this,  and  the  description  of 
the  two  basic  uses  of  SUBNETS  are  provided  in  the  next  two  paragraphs. 

Often,  similar  processing  is  reauired  in  several  different  R_NETs  or 
SUBNETS.  In  such  a  case,  a  SUBNET  is  defined.  The  SUBNET  processing  logic 
is  defined  just  once,  and  then  it  is  REFERRED  (used)  as  a  node  on  any 
structure  where  that  processing  is  needed. 

Its  second  use  is  for  conservation  of  space  in  defining  structures 
which  contain  considerable  processing  logic.  Such  nets  could  be  fully 
defined  to  the  lowest  level  of  detail  on  a  single  page,  but  if  they  were, 
the  resulting  net  would  be  very  complex  and  may  be  more  difficult  to  under¬ 
stand  than  the  more  summary  description  available  by  using  SUBNETS. 

Perhaps  of  more  importance,  there  is  an  adverse  CALCOMP  plot  impact  for 
large  nets  because  of  the  limit  of  CALCOMP-plot  paper  size.  Because  the 
entire  net  will  be  drawn  within  the  boundaries  of  the  available  paper  size, 
structures  with  large  quantities  of  nodes  will  be  drawn  with  the  nodes  so 
small  that  the  names  of  ALPHAs  and  SUBNETS  (which  are  also  included  on  the 
CALCOMP  plot)  will  be  unreadable.  Appropriate  use  of  SUBNETS  to  summarize 
portions  of  the  processing  logic  alleviates  this  CALCOMP  problem. 


3.5.5  Development  of  the  ALPHA  Description  Sheet 

Software  engineers  accomplish  a  parallel  activity  along  with  develop¬ 
ing  the  R_NETs,  and  that's  the  documentation  of  the  DATA  flow  through  the 
R_NET  on  a  worksheet  called  the  ALPHA  Description  Sheet.  Figure  3-18  shows 
this  worksheet  for  the  SUBNET:  PROCESS  XMA_A,  whose  processing  was  just 
described.  The  ALPHA  Description  Sheet  defines  DATA  and  FILE  information 
INPUT  TO  and  OUTPUT  FROM  each  ALPHA  on  the  R_NET  or  SUBNET  covered  by  the 
worksheet.  Consistent  use  of  DATA  names  are  used  in  accordance  with  their 
input  source  and  output  destination.  That  is,  if  the  source  of  a  DATA  item 
was  the  input  MESSAGE,  its  name  must  be  the  same  as  that  which  MAKES  that 
MESSAGE.  On  the  illustrated  worksheet,  the  three  different  described 
ALPHAS  are  the  same  ones  defined  on' SUBNET:  PROCESS_XMA_A  found  in  Figure 
3-17. 

The  DATA  transformations  can  be  observed  on  the  worksheet.  For 
example,  the  first  listed  ALPHA  inputs  two  DATA  items  and  outputs  three. 

The  order  in  which  the  DATA  is  listed  defines  the  intended  transformation. 
For  example,  the  value  for  the  input  DATA  item  UIC_SPT_IN  from  the  input 
MESSAGE,  having  the  SYNONYM  I 2_01_KZ  (abbreviated  on  the  worksheet  as 
01_KZ),  is  stored  in  the  two  DATA  items  UIC_SPT_WON_WORF  (a  portion  of  the 
work  order  number)  and  UIC_SPT_WORF.  Both  of  these  DATA  items  are  stored 
as  GLOBAL  information  in  the  ENTITY_CLASS:  WORK_ORDER_REGISTRATION_FILE_ 
WORE,  which  has  the  SYNONYM  F2_02_8P  (abbreviated  here  as  02). 

Because  no  entry  is  shown  in  the  column  "Value  or  Enumeration", 
whatever  value  is  INPUT  by  UIC_SPT_IN  will  now  reside  in  UIC_SPT_W0N_W0RF , 
and  in  UIC_SPT_WORF.  Note,  however,  that  in  the  second  ALPHA,  only  one 
DATA  item  (ERRORJSODE)  is  shown,  and  it  is  OUTPUT  by  the  ALPHA.  Since 
there  is  no  input  DATA  item  with  a  value  to  be  transferred,  it  is  necessary 
to  indicate  the  value  that  is  to  be  assigned  by  this  ALPHA  to  ERROR_CODE. 
This  value  is  WRONG  JJIC_SPT  and  is  used  in  the  SUBNET:  SEND_PROCESS_ 
ERR0R_MSG  (which  follows  this  ALPHA  on  the  SUBNET  in  Figure  3-17)  where  a 
determination  is  made  as  to  what  error  text  will  be  output  to  the  operator. 
This  item  is  local  because  it  will  be  used  before  processing  in  this  SUBNET 
is  complete,  and  will  not  be  needed  thereafter. 

This  ALPHA  Description  Sheet  also  documents  fwo  other  important 
considerations,  as  shown  at  the  right  side  of  the  worksheet  for  the  first 


ALPHA.  These  two  entries  indicate  that  the  ALPHA:  STORE JJIC  SPT  MR  AND 
SEQ_NR,  in  addition  to  the  input  and  output  of  DATA,  also  CREATES  a  new 
instance  of  the  ENTITY_CLASS:  WORK_ORDER_REGISTRATION_FILE_WORF  and  SETS 
the  new  instance  to  ENTITY_TYPE:  WORK-ORDER-REGISTRATION_FILE_CURR  (the 
current  work  order  file). 

3.5.6  Entry  of  R  NETs  and  SUBNETS  Into  the  Requirements  Data  Base 
Upon  completion  of  the  manual  R_NET  development  and  the  ALPHA 
Description  sheets,  these  efforts  were  described  in  RSL  and  entered  into 
the  requirements  data  base.  The  two-dimensional  structures  were  defined  i 
a  one-dimensional  stream  of  RSL.  For  example,  the  SUBNET  illustrated  in 
Figure  3-17  was  defined  in  RSL,  as  shown  in  Figure  3-19.  This  effort  was 


LIST  paoCESS_>1A_*. 

SUBNET:  PROCESS_XMA^A. 

STRUCTURE: 
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Figure  3-19  RSL  Listing  of  the  Structure  for  SUBNET;  PROCESS_XMA_A 

followed  by  an  RSL  definition  of  the  information  on  the  ALPHA  Description 
Sheet,  and  the  entry  of  this  information  into  the  reauirements  data  base. 
The  result  of  these  RSL  entries  for  the  three  ALPHAS  in  the  SUBNET  in 
Figure  3-17  is  displayed  in  Figure  3-20.  Note  that  two  of  the  ALPHAS  are 
used  (REFERRED)  on  other  SUBNETS  beside  PROCESS  XMA  A.  This  illustrates 


CRaQx  C3*hanO= 

UXST  XNA_A_ACP-*A5. 

A(.P»iia:  S£T_InCOHR£CT  jJIC_S?r_£RfiOP. 

OUTPUTS: 
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QATA:  UIC_CUST_IN. 

3UTPUTS: 
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REFERRED  dt: 
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SUBNET:  P93C£SS_A»a_a. 
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Figure  3-20  RSL  Definition  of  the  ALPHAS  in  SUBNET:  PROCESS  XMA  A 


the  fact  that  all  relationships  are  shown  whenever  an  element  in  the  data 
base  is  listed. 


3.5.7  R  NETs  as  Source  of  Trouble  Reports 

The  development  of  R  NETs  required  nearly  half  of  the  labor  aDDlied 
to  this  effort.  A  total  of  2  R_NETs  and  248  SUBNETS  were  defined  using  the 
technique  described  above.  PerhaDS  it's  not  surprising,  then,  to  note  that 
nearly  all  of  the  discrepancies  identified  and  documented  as  Trouble 
Reports  were  discovered  in  this  phase  of  the  effort.  As  each  DLT  was 
evaluated,  it  was  translated  into  an  R_MET,  and  logical  errors  became  very 
apparent.  A  discussion  of  Trouble  Reports  resulting  from  R_NET  develoD- 
ment,  and  from  efforts  in  other  phases  of  the  contract  is  provided  in 
Section  4  of  this  report. 
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3.6  DEVELOPMENT  OF  TRACEABILITY 

In  a  system  such  as  the  Standard  Army  Maintenance  System  (SAMS)  where 
several  levels  of  requi rements  and  design  soecifications  exist,  both  upward 
and  downward  traceability  should  exist.  This  allows  verification  of  per¬ 
formance  against  the  parent  requirements  and  allows  an  impact  analysis  to 
be  made  in  the  event  that  a  detailed  performance  requirement  cannot  be  met, 
or  a  change  in  the  system  requirement  occurs.  RSL  definitions  that  are 
related  to  traceability  are  provided  in  Table  3.8,  and  their  inter¬ 
relationships  are  shown  in  Figure  3-21. 


Table  3.8  RSL  Definitions  Used  in  the  Development  of  Traceability 


definition  of  elements 

OR  I S I  NAT  INGJEQU I REMENT 

A  HIGHER  LEVEL  OF  REQUIREMENTS  -ROM  WH I CH  .OWER 
LEVEL  REQUIREMENTS.  "HOSE  THAT  ARE  EXPRESSED  IN 

RSL.  ARE  TRACEABLE. 

SOURCE 

SOURCE  OR  AUXILIARY  .MATERIAL  FOR  REQUIREMENTS. 

IT  IS  THE  ORIGINATING  POINT  FOR  DNE  JR  MORE 
ORIGINATING  REQUIREMENT,  THE  DOCUMENTATION  OF 
TRAOE-OFF  STU0IE3,  OR  THE  BACKGROUND  MATERIAL 

FOR  REQUIREMENTS  ELEMENTS. 

decision 

A  CHOICE  OF  INTERPRETATION  THAT  HAS  3EEN  MAOE 

TO  ESTA8LISH  FUNCTIONAL  ANO/OR  PERFORMANCE 
REQUIREMENTS  3ASED  ON  ONE  OR  .MORE  ORIGINATING 
REQUIREMENTS. 

;  DEFINITION  DF  RELATIONSHIPS 

DOCUMENTED  3Y 
v  (DOCUMENTS ) 

IDENTIFIES  THE  ORIGINATING  POINT  OR  PROVIDES 
AUXILIARY  INFORMATION  FOR  THE  ORIGINATING _ 
REQUIREMENT. 

INCORPORATES 
(INCORPORATED  IN) 

INDICATES  A  HIERARCHICAL  RELATIONSHIP  BETWEEN 

OR  I GINATINGJEQU I  REMENTS . 

TRACES  TO 
(TRACED  FROM) 

IDENTIFIES  THE  LOWER  LEVEL  REQUIREMENTS  "0  OR 

from  which  the  originating  requirement  or  decision 

HAVE  3EEN  ALLOCATED  OR  DERIVED. 

The  SOURCE  of  the  ORIGIMAT!NG_REQU I REMENTs  established  in  this  phase 
is  the  text  of  Chapter  A  of  the  DFSR.  We  will  use  an  exerot  from  that 
chapter  to  illustrate  how  the  ORIGINATING_REOUIREMEMTs  are  developed. 

Refer  to  the  exerpt  from  Paragraph  4-10  in  Figure  3-22  for  the  following 
discussion.  In  reviewing  the  contents  of  this  text  to  find  elements  that 
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SOURCE 


documented  by 


(ORIGINATING  REQUIREMENT 


INCORPORATES  INCORPORATED 

I  I  IN 


ALMOS  T> 
ANY  RSL 
JLEMENTx 


(OR  I G I  NAT l NG_REQU I  REMEN  1 


-  TRACES  TO  - 
■TRACED  FROM- 


Figure  3-21  Traceability  Interrelationships 


*-10.  WORK  ORDER  .‘WtAOEMENT  (SEA L  TIME)  PROCESS  (FIGURE  0-6-2).  *he 
Wart  Order  Management  Rrocass  is  a  -eal -time  process  that  prav’des  -j« 
venlcle  for  placing  an  itam  p f  equipment  nto  the  suocort  maintenance 
shop;  Tor  processing  and  controt'  i ng  an  ;  tan  of  equipment  through  'nspec- 
tion,  repair,  and  Tinal  inspection;  anq  cor  -eturnmg  an  •  tam  :f  edu'cmert 
to  the  customer.  This  process  accepts  information  ‘run  the  '‘aintenanca 
Request/Wart  Order  form  by  keying  changes  In  «ork  status  into  the  3 0 
as  they  occur.  This  current  'real-time)  data  is  thus  availaoie  ''or  -.re 
manager  to  secure  current  jtacus  of  the  «ork  orders  in  the  snoos  -'or 
operational  management  purposes  anC  responding  to  customer  ;nouir-es. 

1-lOa.  When  a  Customer  Petarmines  that  suooort  maintenance  -s  ~equ  ■ -ed , 
a  Maintenance  Request; Work  Order,  0A  :;n  ;XXX  ['.2  20  XR)  'S  prepared 
!  (ref  para  a-’,  fig  3—  5— :  5  snd  presented  «>ci  tre  ecu'pment  or  •  tem  to  ;e 
]  repaired  to  the  support  snco.  The  customer  snoulc  enter  my  orevousl/ 
assigned  Work  Order  Mumper,  as  (n  XU"  SRO  :r  Equipment  Recall  schedules. 

A-lQb.  On  '-ecaipt  of  a  s*a’ntenance  Request.  Work  Srcer  ihere'naftan 
ref erred  to  as  Work  Order  (WO)),  the  Shoo  Of'-ca  Clerk  -evews  the 
document  to  insure  that  all  data  are  entered  ma  that  the  fastener  -s 
valid,  if  a  WO  is  received  ‘rrm  a  lonval'P  customer,  the  -0  nay  sit 
be  accaotad,  as  In  the  case  of  a  transient;  newever,  jrress  an  emergency 
exists,  the  customer  is  directed  to  ns  asuai  suooort  amt. 

|  a-iCc.  the  Shoo  Office  Sle^k  creoa.-es  'o  trite-  ~"e  -c-r  "-ter 

!  ‘.i:i  tttt.  J°_<e*s  -t-  ;-t;;  tt  t... 

i  >  .//  -nen  :/  :r~3c  /  t.-g  *:  -  -.o-r  ]  -r.2 

J  ~  ;n  ;  i  3«Z  T~?  en  _ 


-igure  3-22  Excerpt  for  Chapter  ■!  of  the  DF3R  Showing 
ORIGINATING-REOUIREMENT  $ 
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define  a  process  to  be  implemented  by  the  data  processor,  only  a  general 
description  of  the  overall  Work  Order  Management  Process  is  found  prior  to 
subparagraph  4-10c.  Therefore,  no  information  in  these  portions  of  para¬ 
graph  constitutes  an  ORIGINATING_REQUIREMENT. 

As  indicated  by  the  two  blocks  outlined  in  paragraph  4-lQc,  two 

ORIGINATING_REQUIREMENTs  were  found  in  this  subparagraph .  The  first  re¬ 
quires  the  DP  to  recognize  an  operator  request  to  initiate  the  WO  Registra¬ 
tion  process  XMA/XMB.  The  second  requirement  provides  that  the  DP  accept, 
and  presumably  store,  the  DATA  for  Work  Order  Registration.  The  following 
RSL  comnands  established  these  as  ORIGINATING_REQUIREMENTs: 

ORIGINATING  REQUIREMENT:  INITIATE_REAL_TIME_PROCESSING. 

DOCUMENTED  BY  SOURCE:  PARA_4_10C. 

OR I G I  NAT I NG__REQU I REMENT :  PR0MPT_0PR_E NTR Y . 

DOCUMENTED  BY  SOURCE:  PARA_4_10C. 

ORIGINATING_REQUIREMENT:  $TORE_XMA_XMB_WO_REG_ENTRY . 

DOCUMENTED  BY  SOURCE:  PARA_4_10C. 

The  definition  of  processing  in  the  Decision  Logic  Tables  should 
address  these  ORIGINATING_REQUIREMENTs  in  some  defined  process  or  pro¬ 
cesses.  Any  important  element  of  the  requirements  data  base  that  exist  be¬ 
cause  of  these  requirements  should  be  TRACED  FROM  them.  We  define  impor¬ 
tant  elements  as: 

•  SUBSYSTEM 

•  INPUT_INTERFACE 

•  0UTPUT_I  NTERFACE 

•  MESSAGE 

•  ENTITY_CLASS 

«  R_NET 

•  SU8NET. 

Thus,  when  the  requirements  data  base  is  complete,  each  of  the  above  ele¬ 
ment  types  should  be  TRACED  FROM  one  or  more  ORIGINATING_REOUIREMENTs . 
Conversely,  every  ORIGINAT!NG_REOUIREMENT  should  show  a  TRACES  TO  relation¬ 
ship  to  one  or  more  of  the  important  elements,  defined  above. 

If  the  TRACED  FROM  relationship  does  not  exist  for  an  important 
element,  this  suggests  that  the  element  was  not  needed  since  no 
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OR IG INATI MG _ REQU I REMEMT  called  for  it.  And  if  an  ORIGINATTNG_REQUIREMEMT 

does  not  trace  to  any  important  element,  it  implies  that  the  software 
requirements  are  not  complete,  and  won't  be  complete  until  some  portion  of 
the  requirements  statement  is  prepared  to  satisfy  that  QRIG1NATING_ 
REQUIREMENT.  Thus,  at  the  conclusion  of  the  creation  of  the  requirements 
data  base,  RADX  is  used  to  identify  either  of  these  cases  of  faulty  trace- 
ability  so  it  may  be  addressed  b}(  the  software  engineer. 

A  total  of  232  ORIGINATING_R£QUIREMENTs  were  developed  from  Chapter 
A  of  the  MOM  OFSR.  Each  of  the  501  "important  elements"  were  traced  to 
these  ORIGINATING_REOUIR£MENTs.  As  a  result  of  this  effort,  167  important 
elements  were  not  traceable  to  any  ORIGINATING_REQUIREMENT.  Similarly,  47 
ORlGINATING_REQUIREMENTs  did  not  trace  to  any  data  base  element.  These  are 
the  results  of  the  first  pass  of  the  RADX  traceability  check.  Although  we 
lacked  available  computer  time  to  make  corrections,  our  assessment  indi¬ 
cates  that  most  of  the  untraced  elements  were  due  to  human  error  in  the 
data  base.  This  further  illustrates  the  fact  that  although  human  error  can 
occur  with  the  application  of  any  requirements  engineering  technique  ( in¬ 
cluding  SREM),  the  RADX  capability  highlights  all  the  errors  so  that  they 
may  be  corrected.  Consequently,  these  errors  would  have  been  corrected  in 
due  course  in  a  normal  verification  effort. 

With  an  easy  RSL  extension  this  traceability  can  be  continued  to 
software  modules,  test  requi rements ,  test  cases,  etc.  Therefore,  the  data 
base  has  continuing  utility  for  support  of  configuration  management  during 
software  development  and  test,  and  even  after  the  system  is  fielded. 

The  perceptive  reader  will  have  already  recognized  one  additional 
valuable  benefit  of  establishing  strong  traceability  beyond  that  of  config¬ 
uration  management  support.  That  is  the  powerful  support  of  the  assessment 
of  changes  to  the  requirements  that  is  possible.  Suppose,  for  example,  a 
SOURCE  paragraph  was  to  be  deleted  as  a  requirement.  RADX  would  allow  the 
requirements  data  base  to  be  queried  to  produce  a  list  of  elements  that  are 
TRACED  from  the  ORIGINATTNG_REQUIREMENTs  DOCUMENTED  by  that  SOURCE 
paragraph . 

It  does  not  follow  that  all  such  elements  should  be  purged  from  the 
data  base.  Rather,  all  should  be  reviewed  with  an  eye  to  other  processes 
that  are  not  to  be  deleted.  Recognition  of  other  involvement  can  be  gained 
by  noting  the  various  relationships  of  the  elements  on  the  list.  If,  for 
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example,  an  ALPHA  on  an  R_NET,  which  is  to  be  deleted  because  of  the  re¬ 
quirements  deletion,  is  also  on  another  R_NET  which  is  not  to  be  deleted, 
it  must  be  retained.  If  it  was  found  only  on  (REFERRED  BY)  the  R_NET  to  be 
deleted  it  could  safely  be  deleted  from  the  data  base.  Additionally,  the 
DATA  and  FILE  information  INPUT  TO  or  OUTPUT  FROM  that  ALPHA  would  also  be 
examined  and,  if  not  used  for  any  other  purpose,  could  also  be  deleted. 
Thus,  SREM  provides  the  capability  of  removing  unneeded  processing  when  a 
change  occurs,  instead  of  leaving  it  in  place  due  to  the  fear  of  unexpected 
impact  on  other  processing. 
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3.7  EVALUATION  USING  RADX 


The  Requirements  Analysis  and  Data  Extraction  (RADX)  function  built 
into  the  REVS  software  provides  a  means  to  accomplish  powerful  automated 
checks  for  the  completeness,  consistency  and  traceability  of  the  software 
requirements  entered  into  the  data  base  as  a  result  of  the  efforts  des¬ 
cribed  in  the  preceding  paragraphs.  This  is  a  unique  capability,  compared 
to  other  requirements  engineering  tools  and/or  methodologies. 

Because  much  of  the  results  of  our  effort,  including  the  example  of 
the  regeneration  of  the  MOM  DFSR  speci fication,  utilizes  the  RADX  capabi¬ 
lity,  it  is  appropriate  to  describe  rather  thoroughly  how  this  tool  is 
used.  This  will  assist  in  understanding  later  displays  of  information  from 
the  requirements  data  base  and  for  illustrating  the  power  of  RADX  in  its 
support  of  the  software  requirements  engineer. 

In  this  discussion,  we  will  first  define  the  basis  for  the  use  of 
RADX,  describe  how  RADX  is  used  to  create  sets  of  interest  from  the  infor¬ 
mation  in  the  requirements  data  base,  how  to  list  these  sets  for  inspec¬ 
tion,  and  how  to  produce  CALCOMP  plots  from  structures  in  the  data  base. 
With  this  understanding  of  how  RADX  is  used,  we  will  describe  the  steps  we 
took  to  analyze  the  adequacy  of  the  requirements  data  base,  to  include 
examples  where  appropriate  for  understanding.  Finally,  we  will  summarize 
the  problems  found  using  RADX  that  were  reported  via  Trouble  Reports. 

3.7.1  The  Premise  of  RADX  Use 

Conceptually,  RADX  is  built  on  the  premise  that  if  the  preceding 
efforts  were  accomplished  in  accordance  with  the  prescribed  methodology, 
certain  properties  about  the  elements  and  their  relationships  should  be 
true,  if  the  effort  is  complete,  and  conversely,  certain  prooerties  should 
be  absent  if  it  isn't.  For  example,  every  MESSAGE  defined  in  the  data  base 
as  entering  the  DP  system  to  stimulate  some  prescribed  processing,  or  as 
being  produced  during  the  processing  as  a  message  to  be  transmitted  f^om 
the  OP  system  to  an  outside  SUBSYSTEM,  must  be  MADE  3Y  DATA  or  FILE  infor¬ 
mation.  Thus,  any  MESSAGE  that  is  not  MADE  BY  any  DATA  or  FILE  information 
is  a  requirements  data  base  error  that  must  be  corrected.  Once  this 
MESSAGE  is  identified  the  requirements  engineer  will  accomolish  one  of 
three  corrections,  namely:  1)  determine  the  DATA  and  FILE  information  and 
ascribe  it  to  the  MESSAGE  using  the  relationship:  MESSAGE  is  MADE  BY  DATA, 


3-50 


or  MADE  BY  FILE,  or  2)  determine  that  the  MESSAGE  is  really  not  required 
and  PURGE  it  from  the  data  base,  or  3)  determine  that  the  MESSAGE  name  is  a 
slight  variant  of  the  naming  of  another  MESSAGE  in  the  date  base  and  is,  in 
fact,  meant  to  be  the  same  one.  In  this  latter  case,  the  improperly  named 
MESSAGE  is  MERGEd  into  the  correctly  named  MESSAGE  (thus  causing  the  rela¬ 
tionships  and  attributes  of  the  improperly  named  MESSAGE  to  now  be  ascribed 
to  the  correctly  named  one).  In  addition,  the  incorrec'  MESSAGE  name  is 
PURGEd  from  the  data  base. 

3.7.2  RADX  Approach 

The  approach  used  for  RADX  analysis  is  sets  analysis.  A  subset  of 
the  fnformation  in  the  requirements .data  base  is  defined  and  a  RADX  conmand 
is  input  to  create  that  subset.  This  may  be  a  pre-defined  set  such  as  any 
of  the  basic  elements  (e.g.,  ALL  (everything  in  the  data  base),  MESSAGE, 
R_NET,  SUBNET,  DATA,  etc.),  or  may  be  a  user-defined  subset. 

3. 7. 2.1.  Definition  of  a  Set  by  Relationship  Qualification 

The  user  may  define  a  subset  through  the  combination  of  an  element 
and  some  relationship  or  attribute  ascribed  to  that  element.  If  a  subset 
of  MESSAGES  that  are  not  passed  by  an  INPUT_INTERFACE  is  desired,  the  RADX 
conmand  to  establish  that  set  is: 

SET  UNPASSED_MESSAGE$  =  MESSAGE  THAT  IS  NOT  PASSED. 

In  the  example,  the  indicated  elements  are: 

•  SET  The  RADX  command  to  indicate  that  a 

new  set  from  the  requirements  data 
base  is  to  be  established. 

•  UNPASSED_MESSAGES  An  arbitrary  set  ^identifier  (name) 

given  to  the  new  set.  Any  name  may 
be  used  but  is  usually  worthwhile  to 
use  a  meaningful  name. 

•  =  The  definition  of  the  set  just  named 

will  now  be  defined. 

•  MESSAGE  A  predefined  subject  SET  which 

initiates  definition  of  the  SET: 

UNPASSED  MESSAGES. 


•  THAT 


A  legal  positive  connector  which 
will  link  some  relationship  (in  this 
case)  or  attribute  concerning  the 
element:  MESSAGE  to  define  the  set. 

•  IS  An  optional  word  which  may  be  used 

with  this  positive  connector. 

•  NOT  A  legal  connector  that  makes  the 

foregoing  connector  a  negative 
connector. 

•  PASSED  A  legal  relationship  for  the  subject 

SET:  MESSAGE  in  this  set  definition. 

Thus,  this  SET  is  defined  as  all  MESSAGES  that  currently  reside  in  the 
requirements  data  base  that  are  not  defined  as  passing  across  any 
INPUTJNTERFACE  or  OUTPUTJNTERFACE.  Note  that  the  object  elements 
IMPUT_INTERFACE  and  OUTPUT_INTERFACE  did  not  have  to  be  named  to  create 
this  SET.  This  is  because  REVS  recognizes  that  the  relationship  PASSES  is 
legal  only  when  MESSAGE  is  the  subject  element  of  this  definition  and 
either  INPUTJNTERFACE  or  OUTPUTJNTERFACE  is  the  object  element.  Thus, 
when  only  the  relationship  PASSES  i s  used  all  MESSAGES  are  included,  re¬ 
gardless  of  whether  they  are  PASSed  by  the  INPUTJNTERFACE  or  by  the 
OUTPUTJNTERFACE. 

Of  course  the  object  element  may  be  used  in  the  SET  definition  if 
appropriate  to  the  user's  intent  in  creating  the  SET.  For  example,  suppose 
it  was  desired  to  create  a  SET  of  just  the  input  MESSAGES.  In  that  case, 
the  RADX  command  would  be: 

SET  INPUT_MESSAGES  =  MESSAGE  THAT  IS  PASSED  BY  INPUTJNTERFACE. 
This  command  would  create  the  desired  SET.  The  SET  would  not  include 
MESSAGES  PASSed  by  any  OUTPUTJNTERFACE,  nor  MESSAGES  not  PASSed  by  any 
interface. 

The  general  case,  then,  for  a  relationship  Qualification  is: 

SET  Setjdentifier  =  Existingjubject_setJdenti  fier 
Posi ti ve_connector  [or  Neaati vejonnector] 

[MULTIPLE]  Relationship  name  [Relationship  optional  wordl 
[Object  jet  J  den  ti  fi  er] . 

The  bracketed  phrases  represent  optional  portions  of  the  SET  definition. 

All  of  those  shown  except  "MULTIPLE"  have  been  explained.  The  term 


3-52 


"MULTIPLE"  is  used  when  more  than  one  instance  of  the  indicated  relation¬ 
ship  must  exist  for  an  item  to  be  part  of  the  defined  SET.  For  example, 
the  RADX  SET  command: 

SET  MESSAG£S_PAS$ED_BY_MOR£_THAN_ONE_INTERFACE 
=  MESSAGE  THAT  IS  MULTIPLE  PASSED. 

would  create  a  SET  of  all  MESSAGES  that  are  passed  by  more  than  one  inter¬ 
face  (an  improper  condition). 

3. 7. 2. 2  Definition  of  SETs  by  Attribute  Qualification 

SETS  may  also  be  created  by  using  attribute  names,  or  by  using  actual 
attribute  values.  In  the  first  case,  suppose  it  was  desired  to  create  a 
SET  of  R_NETs  that  did  not  have  the  attribute  DESCRIPTION.  The  RADX 
command  would  be: 

SET  UNDESCRIBEDJIETS  =  R_NET  WITHOUT  DESCRIPTION 
The  indicated  elements  in  this  example  are: 

•  SET  The  RADX  command  to  indicate  that  a 

new  set  from  the  requirements  data 
base  is  to  be  established. 

•  UNDESCRIBED_NETS  An  arbitrary  Set_i denti f i er  (name) 

given  to  the  new  set. 

•  =«  The  set  just  named  will  now  be 

defined. 

•  R_NET  A  predefined  subject  SET  which 

initiates  definition  of  the  SET: 
UN0ESCRI3ED_NETS. 

•  WITHOUT  A  legal  negative  connector. 

•  DESCRIPTION  A  predefined  legal  attribute  for  the 

subject  SET:  R_NET. 

The  use  of  the  value  of  an  attribute  to  describe  a  SET  to  be  created 
can  best  be  illustrated  by  another  example.  Suppose  it  was  desired  to  know 
all  the  data  items  with  the  attribute:  UNITS  which  have  the  value 
MANHOURS.  The  appropriate  RADX  command  would  be: 

SET  DATA_WITH_UNITS_OF_MANHOURS  =  DATA  WITH  UNITS  =  MANHOURS. 

-OR- 

SET  DATA  WITH  UNITS  OF  MANHOURS  =  DATA  WITH  UNITS  MANHOURS. 
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When  the  Rel ationa1_operator  in  the  SET  definition  is  ,  it  nay  be  omit¬ 
ted,  since  that  is  the  default  value.  The  general  case  for  attribute  qua! 
ification  is: 

SET  Set_identifier  =  Existing  subject_set  identifier 
Positi ve_connector  [or  Negati ve_connector] 

Attribute_name  [Relational_operator] 

[Attribute_yal  ue] . 

The  legal  relational  operators  are  outlined  in  Table  3.9. 

Table  3.9  RADX  Relational  Operators 


The  value  that  is  specified  for  Attribute_value  can  be  an  integer,  a 
real  number,  a  value  name,  or  a  text  string  that  is  not  longer  than  60 
characters.  The  relational  operators  =  and  <>  are  the  only  ones  that  are 
legal  if  the  value  is  specified  as  a  text  string  or  as  a  value  name  in  the 
set  definition. 

The  members  of  any  new  SET  are  those  members  of  the  existing  subject 
SET  that  satisfy  the  relationship  or  attribute  criterion  in  the  manner 
indicated  by  the  connector.  When  a  positive  connector  is  used,  the  members 
of  the  new  SET  a^e  those  in  the  existing  subject  SET  which  have  the  stated 
relationship  or  attribute  criterion.  If  a  negative  connector  is  used,  then 
the  members  of  the  new  SET  are  those  in  the  subject  SET  that  do  not  have 
the  stated  relationship  or  attribute  criterion.  A  variety  of  terms  are 
allowed  to  be  used  as  positive  and  negative  connectors  to  increase  the 
readability  of  RADX  statements.  The  list  of  legal  connectors  useable  in 
RADX  set  definition  are  shown  on  Table  3.10. 


Table  3.10  RADX  Positive  and  Negative  Connectors 


i 


00 


POSITIVE  CONNECTOR 


NEGATIVE  CONNECTORS 


WITH 
WHERE 
WHICH 
WHICH  IS 
IN 

FROM 

SUCH 

SUCH  THAT 
THAT 
THIS  IS 
BY 


POSITIVE  CONNECTOR  NO 
POSITIVElcONNECTOR  NOT 
WITHOUT 


3. 7. 2. 3  Definition  of  a  Set  by  Enumeration  and  Combination 

Whereas  the  previous  examples  illustrated  SET  definition  in  terms  of 
a  single  existing  subject  SET,  RADX  also  provides  the  means  to  define  new 
SETs  via  use  of  more  than  one  existing  SET.  This  can  be  accomplished  by 
enumeration  or  by  combination  of  existing  SETs. 

In  the  enumeration  approach,  the  members  of  a  new  SET  can  be  defined 
as  those  contained  in  another  existing  SET  or  as  the  union  of  two  or  more 
existing  SET;. 

The  statements  given  below  demonstrate  the  use  of  this  techniaue  for 
defining  SETs. 

SET  A  =  ALPHA,  FILE,  IMPUTJNTERFACE. 

SET  B  =  SET  A,  DATA. 

In  the  first  statement,  SET  A  will  contain  all  the  elements  in  the 
data  base  that  are  members  of  the  predefined  element  type  SETs  ALPHA,  FILE 
or  INPUT_INTERFACE.  The  SET  B  will  contain  elements  that  are  members  of 
the  user  defined  SET  A  plus  the  predefined  element  DATA. 

Defining  Sets  by  Combination 

A  set  can  be  defined  as  the  logical  combination  of  two  existing 
independent  sets  by  a  statement  using  the  following  syntax: 


SET  Set_identifier  =  Existing_first_idenoendent_set_identifier 
Combi nation_operator  Exi sting_second_i ndependent_set_ 
identi fier 

The  combi nation_operators  are: 

e  AND  -  SET  intersecti on.  The  members  of  the  new  SET 
are  those  that  are  members  of  both  the  first 
independent  SET  and  the  second  independent  SET. 

•  OR  SET  union.  The  members  of  the  new  SET  are 

those  that  are  members  of  either  the  first 
independent  SET  or  the  second  independent  SET. 

•  MINUS  -  SET  difference.  The  members  of  the  new  SET  are 

those  that  are  members  of  the  first  independent 
SET,  but  not  the  second  independent  SET. 

Examples  of  SET  definition  by  combination  using  these  operators 
follow: 

•  SET  ALPHA  DATA  =  ALPHA  OR  DATA.  This  combines  all 
ALPHAS  ancT  DATA  into  a  single  SET.  This  provides  the 
same  result  as  the  following  SET  definition  by 
enumeration: 

SET  ALPHA J3ATA  »  ALPHA,  OATA 

•  SET  NETS  IN_X  *  R  NET  and  X.  Here,  X  is  a  user-defined 
SET  whicTT  may  incTude  several  different  predefined  or 
user-defined  SETs.  If  it  includes  R_NETs,  these  R_NETs 
will  now  exist  as  the  SET:  NETS  IN  X.  If  there  are  no 
R_NETs  in  SET  X,  NETS_IN_X  will  5e  an  empty  set. 

•  SET_ALL_EXCEPT_DEC I S ION  =  ALL  MINUS  DECISION.  This 
removes  the  predefined  SET:  DECISION  from  the  total 
existing  requirements  data  base.  The  set  of  remaining 
elements  are  now  defined  as  the  SET:  ALL  EXCEPT 
DECISION. 


3. 7. 2. 4  Defining  SETs  By  Structure  Qualification 

Implicit  relationships  between  structures  and  elements  used  in 
structures  may  be  used  for  defining  a  new  SET  of  elements  that  have,  or  do 
not  have,  certain  structural  characteri sties.  These  implicit  relationshiDs 
are  named  REFERS  and  REFERRED.  They  cannot  be  explicitly  input  through  the 
RSL  tranlator  but  they  are  implicitly  defined  when  a  structure  is  entered 
into  the  requirements  data  base. 

The  REFERS  relationship  exists  between  an  element  with  a  structure 
and  the  elements  used  on  the  strucutre.  The  REFERRED  relationship  is  the 


complement  of  the  REFERS  relationship.  These  implicit  relationships  are 
used  in  the  same  manner  as  RSL  relationships  are  used  to  define  a  new  SET 
by  relationship  qualification.  The  following  examples  illustrate  different 
uses  of  this  statement. 

SET  RJETJIOJTRUCTURE  =  R_NET  WITHOUT  REFERS. 

SET  R_NET  JJS I NG_UPDATE_ST ATE  =  RJ1ET  WHICH  REFERS  TO 
UPOATEJTATE. 

SET  ALPHAS JIOTJJSED  =  ALPHA  THAT  IS  NOT  REFERRED. 

SET  ALL_NEEDED_BY_R_NET_RADAR_SUMMARY  =  ALL  THAT  IS  REFERRED 
TO  BY  RADAR_SUMMARY. 

3. 7. 2. 5  Defining  Sets  by  Hierarchy 
—  —  -  ■■  , 

There  are  several  hierarchies  that  exist  in  the  definition  of  RSL 
such  as  data  hierarchies  and  structure  hierarchies  that  can  be  identified 
for  use  as  a  "road  map"  to  trace  through  the  requirements  data  base  for  the 
purpose  of  defining  a  SET  or  determining  the  order  in  which  to  extract  and 
display  information.  A  RADX  HIERARCHY  can  be  defined  as  follows: 

HIERACHY  [OR  HIER]  New_hierarchy_name  * 

(Existi ng_subject_set_identi fier  Rel ationship_name 
[Relationsbip_optional_word] 

Exi sti ng_ob j  ect_set_i  denti f  i  er ) " 

The  symbol  (  )J  indicates  that  the  type  of  relational  statements  between 
the  parentheses  ()  may  be  repeated  any  number  of  times.  In  the  above 
definition,  New_hierarchy_name  is  a  unique  name  that  will  be  used  to 
reference  the  HIERARCHY.  The  set_i denti fiers  designate  SETs  that  must  be 
defined  before  the  HIERARCHY  is  defined,  and  Rel ationship_name  is  any  RSL 
relationship  or  an  implicit  relation  (REFERS  or  REFERRED). 

For  example.  Figure  3-23,  illustrates  an  RSL  information  hierarchy 
that  exists  in  the  requirements  data  base.  The  nodes  in  the  graph  repre¬ 
sent  SETs  (in  this  case  predefined  element  type  SETs)  and  the  branches 
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Figure  3-23  Hierarchy  for  INPUT  INTERFACE 


represent  binding  relationships  between  the  SETs.  This  HIERARCHY  can  be 
named,  say  INF0_S0URCE,  and  input  under  RADX  for  use  by  defining  the  con¬ 
nectivity  of  the  graph  as  follows: 

HIER  INFOJNTERFACE  »  INPUTJNTERFACE  PASSES  MESSAGE; 

MESSAGE  MADE  3Y  FILE; 

MESSAGE  MADE  BY  DATA; 

FILE  CONTAINS  DATA; 

DATA  INCLUDES  DATA. 

It  may  then  be  LISTed.  Examples  of  LISTed  HIERARCHIES  can  be  found  in 
Figures  3-2,  3-3,  and  others  provided  earlier. 

It  often  is  appropriate  to  create  a  SET  of  all  elements  ‘reversed  v’a 
the  HIERARCHY.  If  it  was  desired  to  create  a  SET  called  INF0_S0URCE  for 
all  the  elements  in  the  HIERARCHY:  INFO_INTERFACE,  it  would  be 
accomplished  as  follows: 
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3. 7.2.6  Listing  RADX  Sets 

Any  predefined  or  user-defined  set  created  under  RADX  procedures  can 
be  listed  by  the  simple  command: 

LIST  Set_identifier 
For  example,  the  command: 

LIST  ALL  or  LIST  ANY 

will  cause  all  elements  defined  in  the  requirements  data  base  to  be  listed. 
The  command: 

LIST  DATA 

will  cause  only  the  DATA  in  the  requirements  data  base  to  be  listed.  The 
command  to 

LIST  X 

(where  X  is  a  user-defined  set)  will  cause  the  user-defined  set  to  be 
printed.  In  addition,  if  it  were  desired,  the  output  could  be  punched 
cards,  rather  than  a  printout,  by  substituting  the  command:  PUNCH  for 
LIST. 

3. 7. 2. 7  Controlling  the  Listing  Format 

When  RADX  is  initially  activated,  all  elements  in  a  RADX  listing  will 
include  all  information  (relationships,  attributes,  structures)  known  about 
each.  The  amount  of  information  to  be  listed  can  be  controlled  by  using 
the  RADX  command  called  APPEND. 

The  APPEND  command  is  used  to  specify  the  associated  attributes, 
relationships,  and  structures  that  should  be  displayed  along  with  the 
display  of  an  element.  The  syntax  of  the  statement  is: 

APPEND  Element_type_identi fier  (Append_item)^. 

The  )"  indicates  that  their  may  be  a  multiple  list  of  Append_items  for  a 
particular  Element_type_identifier.  When  this  is  true,  the  information  is 
printed  in  the  order  in  which  the  Append  item  is  listed. 

In  the  above  statement,  Element_type  identifier  is  an  RSL  element 
type  name,  such  as  MESSAGE,  DATA,  etc.,  or  the  keyword  ANY  or  ALL,  and 
indicates  the  element  type  or  element  types  to  which  the  ADDend  i-em 
applies.  When  ALL  or  ANY  is  specified,  the  ADDend  item  is  aooiied  *o  all 
element  types  in  the  requirements  data  base.  A  list  of  legal  Aooend_i terns 
and  the  information  that  each  causes  to  be  appended  to  an  El ement_type_ 
identifier  is  shown  in  Table  3.11. 
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Ta b  1  e  3.11  Apoend  Item  List 


relation_hame 

a  3ar-:  colas  rsl  relationship. 

at-ri3ute_name 

j  ^hrtio-lar  asl  a— r;3ute. 

REFERS 

ELEMENTS  "HAT  APPEAR  ON  HE  STRUCTURE  OF  HE  SUBJECT 

EL£M€.Nt 

REFERRED 

ELEMENTS  .IH  SHUCHRES  HAT  JSE  HE  SUBJECT  ELEMENT. 

ALL 

I 

ALL  ATH!9u"ES  IN  ALPHABETICAL  ORDER.  POL-OWED  3Y  ALL 

3R I  MAR v  R£_A": UNSHIPS  N  ALPHABETICAL  ORDER,  ;OLlOMED 

3Y  REFERS.  -CL-OhEO  A^ASEHCALl  '  3Y  AL_  IOMPLEMENTARY 
RELATIONSHIPS.  :CL- OWED  lv  REFERRED .  AND  "NALl:  HE 

ELEMENT  S'RLCHRE  OR  path. 

RONE 

NO  ASSOCIATED  INFCRMAIIDN. 

STRUCTURE 

R_Y£T.  SU8NE",  OR  /AL.DATI0N_3ATh  STRUCTURE. 

ATTRIBUTE 

ALl  ATRI3UTJS  IN  ALPHABETICAL  ORDER. 

RELATION  \ 

RELATIONSHIP  J 

ALL  PRIMARY  RELATIONSHIPS  IN  AL?hA8£t!0Al  ORDER  -OL-OWEO 

3Y  ALL  OOMPLEMENTARY  RELATIONSHIPS  IN  ALPHABETICAL  ORDER. 

PRIMARY 

ALL  PRIMARY  R£_A*IONSn!?S  IN  ALPHABETICAL  ORDER. 

COMPLIMENTARY 

ALL  COMPLEMENTARY  RELATIONSHIPS  IN  ALPHABETICAL  ORDER. 

o.7. 2. 8  Displaying  Structures 

The  command:  PLOT  provides  a  means  for  attaining  a  CALCOMP  plot  for 
any  structure  which  has  been  entered  into  the  data  base.  The  general  form 
of  the  command  is: 

PLOT  Exi sti ng_structure_el ement  Plot  size. 

The  term  Exi sti ng_structure_el ement  means  R_NET,  SUBNET,  or  VALIDATION 
PATH.  The  term  Plot_size  refers  to  the  desired  size  of  the  reauested  plot. 
This  is  written  as: 

WIDTH  =  Width_value,  HEIGHT  *  Height  value. 

The  Width_value  and  Height_yalue  are  stated  in  inches  and  as  a  real  or 
integer  number  up  to  50  and  29,  respectively.  The  default  values  (if  no 
values  are  provided)  are  8  and  10,  respectively. 

Figure  3-17,  shown  earlier,  illustrated  a  hand  drawn  SUB ME"  whose 
structure  was  translated  into  RSI  and  placed  in  the  '•eaui rements  data  base. 
Figures  3-2A  and  3-25  provide  its  CALCOMP  equivalent  from  the  data  base. 
Note  that  the  resulting  plot  is  actually  two  pages  of  output.  The  plot  of 
the  SUBNET  is  shown  Figure  3-24.  "he  title  of  the  SUBNET  is  shown  at  the 
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PROCESS  _xnfi  _q 
STRUCTURE  UESENO 

CONDITIONAL  EXPRESSIONS  ANO/OR  COflHE.NTS 


1 

2 

3 

4 


tUIC_SPT_CRF=UlC_SPT_INl 

I FOUNO 1 

OTHERWISE 

C  tUIC_SPT_C.RF=UJC_3PT_INI  AND 

(UIC _CUSr_CRF_3=UIC_CUST_!N)  ! 


NOOE  OROINflL 
i a  ^RuuE 


Figure  3-25  Conditional  Expressions  for  the  CAICOMP  Plot  for  SUBNET: 
PROCESS  XMA  A 
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top  of  the  plot.  The  plot  looks  similar  to  its  hand-drawn  eauivalent  in 
Figure  3-17,  except  that  the  conditional  expressions  found  on  the  branches 
of  the  hand-drawn  SUBNET  are  replaced  by  numbers  on  the  CALCOMP  version. 

The  second  sheet  of  the  CALCOMP  plot  (Figure  3-25)  defines  the  conditional 
expressions  represented  by  these  numbers  and  also  provides  any  comments 
that  may  have  been  entered  for  the  structure.  This  two-page  approach  was 
selected  due  to  its  ease  of  implementation  during  development,  and  has  not 
been  subsequently  improved.  This  feature,  and  certain  other  awkward  as¬ 
pects  of  the  current  CALCOMP  plot  capability  represent  one  of  the  REVS 
areas  that  deserves  improvement,  such  as  the  inability  to  be  read  when 
there  is  a  large  number  of  nodes  on  the  structure. 

3. 7. 2. 9  Combined  Static  RAOX  Tests 

In  order  to  reduce  the  load  on  the  software  engineer,  and  to  assure 
a  complete  RADX  check  is  made  of  the  requirements  data  base,  a  set  of 
standard  RADX  commands  has  been  derived  for  all  appropriate  RADX  tests. 

These  have  been  organized  in  groups  related  to  specific  phases  of  the 
methodology  and  stored  as  ADDFILEs  far  access  after  each  phase  is  complete. 

Such  tests  exist  for  Phases  1,  2,  3,  4,  and  6.  Phases  5  and  7  are  simu¬ 
lation  phases,  and  no  static  RADX  tests  are  used  in  these  phases.  When 
used,  any  LISTed  SETs  indicate  failure  of  the  software  engineer  to  consis¬ 
tently,  completely,  and  unambiguously  describe  the  software  requirement  in 
accordance  with  the  SREM  procedures.  Attention  should  be  given  to  the 
items  listed  to  correct  the  indicated  problems.  A  comment  is  provided  for 
each  LIST  command  to  describe  what  error  the  members  of  the  SET  possess,  or 
to  describe  the  intent  of  the  RADX  test  whose  result  is  being  listed.  A 
listing  of  the  kinds  of  tests  performed  for  each  phase  of  SREM  are  provided 
in  Tables  3-12  through  3-16  for  Phases  1,  2,  3,  4,  and  6,  respectively. 

Several  of  the  combined  RADX  tests  appropriate  for  the  MOM  DFSR 
effort  were  administered  to  the  requirements  data  base.  The  results  of 
these  tests  are  provided  in  Appendix  C.  Normally,  each  of  the  indicated 
problems  would  be  corrected,  and  many  of  the  answers  needed  for  this 
correction  would  come  from  the  user.  However,  under  this  contract,  there 
is  no  user,  and  therefore,  no  correction  of  the  data  base  has  been 
attempted. 
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Table  3.12  SREM  Phase  1  RADX  Checks 


t  ENTtTY'LASS 


I  »  HOT  CREATED 

!  •  HOT  DESTROYED 

|  «  nitholt  entity .type 

entity.typs 


•  HOT  set 

•  HOT  IN  AM  ENTITY.CLABS 

*  in  none  than  one  entity  .class 

HE 5 SAGS 

*  OUTPUT  MESSAGES  HOT  FORMED 


Table  3.13  SREM  Phase  2  RADX  Checks 


PROVIDES  FOR  VISUAL  DHECX 

«  entitv.class  hierarchies 

«  FREE  STANDING  F1LE3 

•  FREE  STANDING  DATA 

•  INPUT. INTERFACE  HIERARCHIES 

•  OUTPUT.INTERFACE  HIERARCHIES 

PROBLEM  REPORTS 
«  OPEN  PROBLEMS 

•  NOT  TRACED  FROM  OR  I G I  NAT  I NG.REOU I REMENT  OR  ANOTHER  DECISION 

«  not  traced  to  elements  it  mill  impact 

5U8STSTEMS 

•  UNCONNECTED 

interpaces 

•  unconnected 

•  CONNECTED  to  none  than  one  subsystem 
»  PASSES  no  messages 

(  AN  INPUT- INTERFACE  DOESN'T  enable  R-MET 


•  HITHOUT  DATA  DR  FILES 

•  NOT  PASSED  3Y  AN  INTERFACE 

•  passed  ar  more  than  one  interface 

R.NCTS 

•  hot  enabled  ar  an  input.interface  or  event 

•  MULT  t. ENABLED 

•  ENABLED  3Y  INPUT. INTERFACE  NOT  ON  STRUCTURE 
EVENTS 

«  OOESN'T  ENABLE  AN  R.MET 

•  DELAYED  3Y  DATA  HOT  AT  LOWEST  LEVEL 

•  DELAYED  3Y  MORE  THAN  ONE  DATA  ITEM 

STRUCTURES 

I  t  AN  ALPHA,  SUBNET,  EVENT,  'ALJ DAT lON.’OINT,  INPUT. INTERFACE,  OR 
3UTPUT .INTERFACE  DOES  NOT  AF"EA»  DN  A  STRUCTURE 
[  «  .DGiC  HOT  DEVELOPED  :OR  DEr'HED  STRUCTURE 

i  ENTITIES 

i  I  ENT ITV.SLASS  OR  SNE  OF  ITS  ENT  IT'  .*v»« 3,'  NEVER  SELECTED  DN  A 
[  STRUCTURE 

•  ENTITY  .TYPE  DOES  HOT  HONTAIN  ANY  DATA  DR  :’LES 


rfro-iPiw 


Table  3.14  SREM  Phase  3  RADX  Checks 


FILE  ORDERING 

•  MULTI .ORDERED  FILES 

•  FILE  ORDERING  DATA  NOT  IN  A  FILE 

•  NON.LQWEST  LEVEL  ORDERING  DATA 

FILE  CONSTRUCTION 

•  EMPTY .FILES 
DATA 

•  NEITHER  A  SINK  NQR  A  SOURCE 

•  SOURCE.  BUT  NO  SINK 

•  SINK  BUT  NO  SOURCE 

•  MISSING  RANGES  FOR  ENUMERATED  DATA 

•  RANGE  FOR  TYPES  OTHER  THAN  ENUMERATION 

•  NO  TYPE 

•  USE  INFORMATION  (NEEDED  FOR  SIMULATIONS) 

•  DATA  IN  MORE  THAN  ONE  PILE 

•  DATA  IN  MORE  THAN  ONE  ENT !TY_CLASS 

•  DATA  IN  BOTH  AN  ENT ITY_CLASS  AND  ENT ITY.TYPE 

I  DATA  IN  BOTH  AN  ENTITY  AND  IN  A  FILE 

•  DATA-IN  BOTH  AN  ENTITY  AND  IN  A  MESSAGE 

•  DATA  IN  BOTH  A  MESSAGE' ANO  A  FILE 

•  LOCAL  DATA  IN  ENTITIES 

•  GLOBAL  DATA  IN  MESSAGES 

•  LOCAL  DATA  IN  A  GLOBAL  FILE 

•  GLOBAL  DATA  IN  A  LOCAL  FILE 


Table  3.15  SREM  Phase  4  RADX  Checks 


TRACEABILITY 

•  ORIGINATING  .REQUIREMENTS  THAT  DON'T  TRACE  TO  OTHER  ELEMENTS 

•  DECISIONS  THAT  DON'T  TRACE  TO  OTHER  ELEMENTS 

•  SOURCES  THAT  WEREN'T  USED 
AUTHORSHIP 

•  UNAUTHORED  DATA  3ASE  ELEMENTS 
DESCRIPTIONS 

•  UNDESCRIBED  NETS 
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Table  3.16  SREM  Phase  6  RADX  Checks 


1  validation  points 

•  NOT  PLACED  ON  A  NET 

•  PLACED  ON  MORE  THAN  ONE  NET 

•  DOESN'T  RECORD  ANY  DATA  OR  FILES  FOR  TEST 
PERFORMANCE  REQUIREMENTS 

•  HAS  NO  TEST  WRITTEN  FOR  IT 

•  HAS  NO  VALIDATION  PATH  FOR  IT 

•  NOT  TRACED  FIOM  AN  OR IG I  NAT ING.REQUt REMENT ,  A  DECISION,  OR  A  SOURCE 
VALIDATION  PATHS 

•  NOT  CONSTRAINED  8T  A  PERFORMANCE.REQU I REMENT 
PROVIDES  FOR  VISUAL  CHECK 

•  PERFORMANCE  ..REQUIREMENTS  WITHOUT  CONSTRAINS  TO  CHECK  AGAINST 
VAL I  DAT  I ON_P ATHS  NOT  CONSTRAINED 

•  UNCONSTRAINED  VALIDATION  PATHS  TO  SEE  IF  A  PERFORMANCE_REQU I REMENT 
SHOULD  BE  WRITTEN  TO  CONSTRAIN  IT 

•  SHOWS  HOW  MANY  PERFORMANCE_REQU I REMENTS  EACH  VAL 1  DAT  1 ON_PATH 
IS  CONSTRAINED  BY 

•  SHOWS  HOW  MANY  VAL 1  DAT  I  ON _P ATMS  ARE  CONSTRAINED  BY  EACH 
PERFORMANCE  REQUIREMENT. 


3.7.2.10  Oata  Flow  Analysis 

The  final  static  RADX  test  of  the  data  base  is  the  data-flow 
analysis.  This  is  accomplished  by  the  command: 

ANALYZE  DATA_F10W  Structure_set_i denti fier . 
where  Structure_set_identi fier  is  a  class  of  structures  (such  as  R  MET), 
is  the  name  assigned  for  the  particular  R_MET  or  SUBNET  whose  analysis  ’s 
desi red. 

The  basic  data-flow  tests  of  interest  are: 

•  Loop  Detection:  Identifies  any  loops  that  may  have  been 
inadvertently  introduced  due  to  faulty  SUBNET 
referencing  or  a  recursive  DATA  definition  via  the 
INCLUDES  relationship. 

•  LOCALITY  Attribute  Test:  Checks  the  LOCALITY  attribute 
for  DATA  and  FILES  used  or  produced  in  the  R_MET  to 
determine  whether  LOCAL  or  GLOBAL.  It  then  assures  that 
appropriate  use  is  made  in  accordance  with  the  assigned 
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LOCALITY.  For  example,  only  LOCAL  DATA  and  FILES  may  be 
in  a  MESSAGE  and  only  GLOBAL  DATA  and  FILES  may  be 
ASSOCIATED  with  an  ENTITY_CLASS  or  ENTITY_TYPE . 

•  Membership  Test:  Identifies  inadvertent  inclusion  of  a 
DATA  item  in  more  than  one  repetitive  data  set  (ENTITY 
CLASS,  ENTITY_TYPE,  or  FILE). 

•  Conditional  Branching  Tests:  Checks  for  ambiguous  or 
incomplete  statement  of  branching  condition. 

•  Net  Structure  Test:  Checks  for  SUBNETS  that  are 
REFERRED,  but  which  do  not  have  processing  logic 
defined,  and  for  incorrect  structure  logic  caused  by 
improper  rejoins  after  OR  or  AND  node  branching. 

•  Information  Assignment/Usage  Tests:  Checks  for 
information  used  without  a  source,  and  information 
assigned  (produced)  that  is  not  used. 

•  Ambiguous  Flow  Test:  Checks  to  see  if  the  change  in  the 
sequence  of  processing  of  paths  initiated  by  an  AND  node 
could  cause  the  source  of  information  for  any  following 
R_NET  node  to  change. 

After  listing  the  flow  of  DATA  within  the  R_NET,  the  MESSAGES  input  to  the 
R_NET  and  produced  by  it  (with  the  FILE  and  DATA  that  MAKES  them),  any 
errors  detected  by  the  tests  described  above  are  listed.  The  locations  of 
errors  in  the  R_NET  are  pin-pointed  by  a  list  of  walk  back  information 
which  shows  the  preceding  nodes  in  the  order  traversed  from  each  error  node 
back  to  the  top  of  the  R_NET.  An  example  of  a  data  flow  analysis  for  the 

XMA  Real-Time  Process  will  be  found  in  Appendix  C. 
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3.9  ANALYSIS  OF  THE  SREM  APPLICATION  EFFORT 


During  the  period  of  performance  two  requirements  engineers  worked 
full  time  on  this  effort,  two  others  worked  part  time,  and  supervision 
added  an  equivalent  effort  of  just  over  one-half  a  person.  Over  the  ap¬ 
proximately  6-1/2  months  of  technical  activity  this  was  the  equivalent  of 
just  under  2-2/4  requirements  engineers.  The  SREM  engineering  effort 
applied  to  evaluation  o*  the  MOM  DFSR  totals  2660  man-hours.  Engineering 
man-hours  were  allocated  to  16  identifiable  tasks  as  shown  in  Table  3.17. 
Since  the  R_NET  is  the  focal  point  of  SREM  activity,  much  time  was  spent  on 
it  for  the  MOM  DFSR.  It  has,  historically,  been  one  of  the  most  time 
consuming  activities.  A  total  of  1152  man-hours  have  been  applied  to  date 
to  defining  R_NETs.  That  is  43.1  percent  of  the  total  engineering  time 
applied  in  this  effort. 


Table  3.17  SREM  Task/Time  Allocation 


Naurs  Applied 

4  OF  TOTAL  HOURS  APPLIED 

SPECIFICATION  RESEARCH 

23 

,34 

RECORO  PROBLEMS 

146 

5.54 

OEFTNE  SUBSYSTEMS 

20 

.34 

DEFINE  INTERFACES 

26 

.94 

5<i 

2.04 

OEFTNE  MESSAGE  CONTENTS 

196 

7.14 

qefine  r  vets 

1152 

13.14 

ENTITY  CLASS 

11 

1.54 

ENTITY  T/P? - 

0 

.25 

ENTITY  DATA  DETAIL 

5 

.25 

ESTABLISH  TRACEA8IL;Tv 

149 

5.75 

STATIC  PAOX 

166 

5.3% 

3EV!5c  DAT  A  3A:5c 

188 

requirements  regeneration 

112 

S.35 

SREM  EVALUATION 

25 

.95 

REVIEW  1  COORDINATION 

172 

FINAL  REPORT 

1 18 

5.7% 

As  stated  earlier  in  this  reoort,  R  NETs  are  developed  to  describe 
the  stimulus/response  relationship  required  of  software  to  process  each  of 
the  input  messages.  Because  of  the  unique  view  of  processing  provided  by 
this  technique,  most  of  the  specific  problems  in  the  software  soeci fi cati on 
were  found  during  the  process  of  defining  R  METs.  Tbose  problems  were 
documented  by  Trouble  Reports,  the  time  for  which  is  reported  under  Record 
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Problems.  A  total  of  146  man-hours,  or  5.5  percent  of  the  effort,  was 
applied  to  this  task. 

Prior  to  the  definition  of  R_NETs,  some  preliminary  tasks  had  to 
occur.  These  tasks  included  Specification  Research,  Definition  of 

SUBSYSTEMS,  Definition  of  Interfaces,  GLOBAL  DATA  Definition  ( ENTITY _ 

CLASSES ,  ENTITY_TYPEs,  and  ASSOCIATED  DATA  detailing).  A  total  of  122 
man-hours  were  applied  to  these  tasks,  or  4.5  percent  of  total  man-hours 
applied.  Another  preliminary  effort  included  defining  MESSAGES,  MESSAGE 
contents,  and  establishing  traceability.  In  all  the  preliminary  efforts, 
translation  and  entry  of  the  defined  elements  and  their  relationships  into 
the  requirements  data  base  was  accomplished  concurrently,  and  is  included 
in  the  totals.  These  tasks  required  399  man-hours,  or  15  percent  of  total 
man-hours  applied.  RADX  testing,  data  base  correction,  and  the  regenera¬ 
tion  of  requirements  utilized  496  man-hours,  or  18.7  percent  of  the  total. 
The  man-hours  applied  to  administrative  type  tasks,  such  as  SREM 
Evaluation,  Review  and  Coordination,  and  Final  Report  preparation  totalled 
345  or  13  percent  of  total  man-hours  applied. 

Our  past  experience  indicates  that  the  best  estimating  relationship 
for  determining  the  amount  of  effort  needed  for  a  SREM  application  is  based 
on  the  number  of  input  MESSAGES  and  EVENTS  that  stimulate  the  R_NETs  that 
must  be  defined.  In  this  effort,  there  have  been  62  input  MESSAGES  and  no 
EVENTs.  A  total  2660  man-hours  have  been  applied  to  the  effort,  thus 
averaging  42.9  man-hours  per  stimulus.  Previous  experience  indicates  that 
approximately  40  man-hours  per  stimulus  is  typical,  which  is  comparable 
with  the  MOM  DFSR  effort. 

The  average  is,  however,  somewhat  understated  because  of  certain 
peculiarities  we  experienced,  although  they  probably  are  typical  of  infor¬ 
mation  systems  of  this  type.  Some  of  the  character!' sties  of  the  software 
specification  that  differ  in  this  application  compared  to  most  of  our  pre¬ 
vious  applications  are: 

•  Larger  set  of  input  and  output  MESSAGES. 

•  Larger  GLOBAL  data  base  as  reflected  in  the  number  of 
ENTITY  _CLASSes  defined. 

•  Logical  strings  of  ooerator/data  processor  interactions 
( e . g. ,  promot,  operator  response,  error  message  and 
reprompt,  operator  response,  next  promot,  etc.). 
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•  Considerable  introduction  of  design  into  the  require¬ 
ment,  particularly  the  heavy  use  of  pre-sorting. 

SREM  was  designed  to  develop  and  express  the  logical  functional  and 
performance  requirement,  and  not  to  express  actual  implementation.  To  the 
extent  that  such  implementations  are  introduced,  SREM  application  efforts 
increase.  Because  of  implementation  in  the  MOM  DFSR,  and  the  other  prob¬ 
lems,  discussed  earlier,  approximately  half  of  our  effort  was  at  a  level  of 
summary  higher  than  normal.  Although  this  probably  resulted  in  finding 
fewer  deficiencies  in  those  areas  where  the  approach  was  used,  it  did  allow 
us  to  complete  the  requirements  data  base  so  that  important  RADX  tests 
could  be  made.  We  estimate  that,  had  the  engineering  assessment  been 
totally  applied  at  the  normal  level  of  effort,  the  application  time  pro¬ 
bably  would  have  increased  about  25  percent  per  input  MESSAGE. 

If  we  had  not  taken  the  generic  approach  to  the  real-time  input  of 
information,  rather  than  treating  each  of  the  approximately  570  data  items 
that  could  be  entered  as  separate  MESSAGES,  application  time  to  define  this 
processing  would  have  been  significantly  larger.  We  believe  the  impact  of 
processing  every  data  item  as  a  separate  MESSAGE,  as  a  literal  interpreta¬ 
tion  of  this  specification  would  have  increased  the  application  effort  by 
about  300  hours.  This  would  amount  to  slightly  more  than  double  the  over¬ 
all  effort;  under  this  contract,  about  36  man-months. 

For  specification  the  size  of  the  MOM  OFSR  three  man-years  of  effort 
seems  reasonable,  when  compared  to  the  advantages  that  will  result  from 
having  a  complete,  consistent,  and  unambiguous  specification  from  which  to 
re-accompl ish  software  design.  We  believe  that  much  more  than  this  amount 
of  effort  and  cost  would  be  saved  over  the  remaining  life  cycle  of  the 
development  of  this  software  package.  An  even  more  positive  savings  would 
have  resulted  if  the  software  specification  had  been  originally  developed 
with  SREM.  For  more  discussions  of  software  development  costs  and  the 
impact  of  SREM  in  reducing  them,  see  Section  5. 


4.0  RESULTS  OF  SREM  APPLICATION 


In  preceding  sections  we  have  described  the  basic  components  of  SREM, 
illustrated  how  we  defined  pertinent  information  to  create  the  requirements 
data  base  for  the  MOM  DFSR,  and  described  how  we  evaluated  the  data  base 
using  the  automated  RAOX  capability.  During  those  activities,  identified 
deficiencies  in  the  specification  were  documented  in  Trouble  Reports  and 
entered  into  the  data  base.  The  purpose  of  this  section  is  to  describe  the 
results  of  this  effort  which  (for  a  verification  effort  of  this  type) 
primarily  are  the  documented  deficiencies.  An  added  effort,  described 
herein,  is  the  description  of  the  regeneration  of  the  requirements  from  the 
REVS  data  base. 
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4.1  DESCRIPTION  OF  TROUBLE  REPORTS 

The  attainment  of  good  software  requirements  is  not  easy.  Even 
though  the  desirable  characteri sties  of  a  good  specification  are  well 
understood,  capturing  those  qualities  in  the  production  of  software  speci¬ 
fications  has  proved  elusive.  The  major  qualities  that  are  sought  were 
described  in  Paragraph  2.2.  The  development  of  SREM  had  the  goal  of 
attaining  these  qualities,  when  used  to  develop  the  original  software 
requi rements .  It  has  also  proven  its  capability  to  identify  the  lack  of 
these  qualities  within  existing  software  specifications  in  its  verification 
role. 

Recognized  deficiencies  in  the  MOM  DFSR  were  documented  using  a 
Trouble  Report  form  as  a  worksheet,  for  eventual  entry  into  the  data  base. 
Normally,  these  Trouble  Reports  would  have  been  submitted  to  the  organiza¬ 
tion  which  had  developed  the  specification  to  attain  theiv'  response  con¬ 
cerning  corrective  action.  In  this  effort,  no  such  organization  existed 
and,  therefore,  the  MOM  DFSR  has  not  been  totally  corrected.  Rather,  the 
deficiencies  have  simply  been  recorded  to  evidence  the  results  of  the 
verification  effort. 

4.1.1  Trouble  Report  Format 

The  Trouble  Report  form  (Figure  4-1)  is  an  AIRMICS  version  of  a 
standard  form  that  was  designed  for  the  interaction  between  the  developer 
and  verifier.  Problems  found  by  the  verifier  are  described  as  completely 
as  possible  in  the  "PROBLEM"  block  so  as  to  assure  understanding  by  the 
developer.  If  any  alternatives  appear  appropriate  for  solving  the  PROBLEM, 
they  are  included  in  the  "ALTERNATIVES"  block  by  the  verifier.  The 
remainder  of  the  header  blocks  are  also  completed  by  the  verifier  and  the 
Trouble  Report  is  forwarded  to  the  developer.  His  choice  of  alternatives 
or  other  solution  is  reported  back  to  the  verifier,  usually  using  the 
"CHOICE"  block  for  his  reply.  Since  we  had  no  developer  responses,  we 
filled  in  the  "CHOICE"  block  on  each  Trouble  Report,  wherein  we  suggested 
the  action  needed  to  correct  the  stated  PROBLEM. 

In  order  to  develop  statistics  on  the  kinds  of  deficiencies  being 
identified,  a  "CATEGORY  OF  PROBLEM"  block  was  provided  for  five  specific 
categories,  plus  an  "OTHER"  category.  The  definitions  we  applied  in  deter¬ 
mining  these  deficiency  categories  are  as  follows: 


TROUBLE  REPORT  NR 

DATE  PREPARED 

DATE  CLOSED 

SOURCE 

Of 

TROUBLE 

REPORT 

□  □ 

1  TM  38-171-2:  OFSR  SAMS  1  (MOM)  PAGE  NR  _ 

TM  33-1.72-2:  OFSR  SAMS  2  (MPOM)  PAGE  NR. _ 

TA8LE  .NR 

PARAGRAPH  NR 

FIGURE  NR 

DECISION: 


TRACES  TO: 


I  TRACED  FROM: 


CATEGORY 
OF  PROBLEM 

O  AFBIGUCUS 
O  MISSING 
O  INCONSISTENT 
O  INCOMPLETE 
O  ILLOGICAL 
O  OTHER : 


o 

oe 

a. 


PROBLEM: 


5  S 

£  * 

a  _ 

-x  at 
a.  O 

S  ST 

5  3 

xt  g 

l/»  — 

<  <-» 


ALTERNATIVES: 


CHOICE: 


TROUBLE  REPORT  PREPARED  3Y 


OATE  ENTERED  IN  DATA  EASE 


G PROVIDED  FOR  INFORMATION  ONLY 

O  RESPONSE  REQUESTED 

«/»  £ 

— 

is 

<« 

AIRMICS  RESPONSE  3Y 

CATE  OF  RESPONSE 

Figure  4-1  AIRMICS  Trouble  Report  Form 
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•  AMBIGUOUS:  Processing  requirements  f^om  flowcharts, 
decision  logic  tab!  s,  and  processing  subparagraphs 
present  unclear  intentions  due  to  vague  descriptions  of 
logic  paths,  unclear  naming  or  use  of  data,  or  descrip¬ 
tions  that  defied  determination  of  the  true  intent  of 
described  processing. 

•  MISSING:  Data  that  is  defined  as  being  used  or  produced 
during  processing,  but  is  missing  from  Annex  C  of  the 
DFSR,  as  well  as  steps  or  tables  referred  to  in  the 
DLTs,  but  which  were  actually  missing.  Certain  RADX- 
discovered  problems  also  fall  in  this  category. 

•  INCONSISTENT  Data  names  that  are  different  for  identi¬ 
cal  data  items,  same  data  name  used  for  different  data 
items,  and  different  data  having  the  same  (and  there¬ 
fore,  ambiguous)  names.  Also  included  are  processing 
steps  that  are  inconsistent  between  DLTs, 

•  INCOMPLETE:  Processing  requirements  from  DLTs  that  omit 
processing  logic  and/or  other  required  information. 

Certain  RADX  discovered  problems  also  fall  in  this 
category. 

•  ILLOGICAL:  Processing  requirements  from  DLTs  that 
present  processing  steps  in  an  illogical  order,  such 
that  the  intended  processing  cannot  be  attained. 

4.1.2  Entry  of  Trouble  Reports  into  the  Requirements  Data  Base 

When  completed,  the  Trouble  Report  information  was  translated  from 
the  forms  into  RSL  and  entered  into  the  requirements  data  base.  This  was 
accomplished  by  using  the  basic  RSL  element:  DECISION.  DECISION  has 
predefined  attributes  and  relationships  that  match  major  portions  of  the 
Trouble  Report.  These  include: 
t  Relationships: 

-  TRACES  TO  (any  RSL  Element) 

-  TRACED  FROM  ORIGINATINGJEQUIREMENT 

•  Attributes:  *, 

-  PROBLEM 

-  ALTERNATIVE 

-  CHOICE 

-  TROUBLE  REPORT  ;)C!Ep4RED  gy  (-alled  ENTERED_3V  in 
RSL). 


3ecause  RSL  is  easily  extensible,  other  items  on  the  Trouble  Report 
were  created  as  new  RSL  elements  with  new  relationships  to  DECISION,  or  as 
new  attributes  for  DECISION.  These  included  the  following  items: 

•  Relationships: 

-  SH0WN_0N  REF_L0CATI0N  (Page  Number) 

-  IDENTIFIED_SY  TROUBLE_R£PT_NR 

•  Attributes: 

-  DATE_PREPARED 

-  CATEG0RY_0F_PR0BLEM  (AMBIGUOUS,  MISSING,  ETC.) 

-  DATE  _CL0SED . 

The  extension  of  the  RSL  to  allow  the  above  changes  to  translate  suc¬ 
cessfully  for  acceptance  and  storage  is  accomplished  quite  easily.  The 
necessary  RSL  commands  to  accomplish  this  extension  are  shown  in  Figure 
4-2. 


EL£.MENr_TYRS :  TS3uaL£_at',T-NS  (•  *i. 
delation.-  roeNns'its  7*  *!. 

COMPLEMENTARY  delation:  IDENT IF  I ED_9  r . 

Subject  SL£MENT_rYRe :  trou8ls_RE?t_nr. 
OBJECT  ELEMENT _T  YPE :  DECISION. 
ATTRIBUTE:  CATE30RY_OF_PR08LEM  (♦  •). 
APPLICABLE:  DECISION. 
valJE :  AW8I3U3US. 

VALUE:  YISSIN3. 

VALUE:  INCONSISTENT. 

VALUE:  INCOMPLETE. 

VALUE:  ILLOGICAL. 

VALUE:  OTHER. 

A  TTR I  3 j  T  E :  0aTE_5R£RaRE0  <*  •). 
APPLICABLE :  OECISION. 

VALUE:  TEXT. 

ATTR J  a JT£ :  0aTE_:l3ScD  (•  •>. 

AO°Ll CABLE :  OECISION. 

VALUE:  'EXT. 

ELEmEn  r_’YOE :  RELOCATION  <*••>. 
RELATION  SHOWS  (•  •)  . 

Complementary  relation:  3mo«n_on. 
SUBJECT  w£f_ LOCATION. 
object  OECISION. 
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Figure  4-2  RSL  Extensions  to  Support  ^rouble  Report  Entries 


4.1.3  RAOX  Support  of  Management  Review  of  Trouble  Report 

RADX  was  used  throughout  this  project  to  assure  completeness  of  the 
"rouble  Reports  in  the  data  base.  The  kinds  of  checks  made  by  RADX  includ¬ 
ed  the  following: 

•  Missing  TR  numbers. 

•  Missing  PROBLEM  statements. 

•  Missing  page  number  source, 

•  Missing  traceability  to  ORIGINATING_R£OUIREMENTs. 

•  Missing  CATEGORv_0F_PR08L£M. 

•  Missing  CHOICE. 

The  RADX  commands  necessary  to  automatically  check  through  the  large  number 
of  Trouble  Reports  for  the  kind  of  problems  outlined  above  is  shown  in 
Figure  4-3,  and  is  in  the  same  order  as  the  above  list.  Wherever  the  SET 
COUNT  is  zero,  there  are  no  problems  of  that  type.  If  the  SET  COUNT  is 
greater  than  zero,  a  command  to  LIST  the  SET  will  provide  the  names  of  the 
DECISIONS  which  are  deficient  in  the  way  defined  in  the  SET  so  that  the 
missing  information  can  be  provided.  ' 

A  critical  management  function  is  control.  The  manager  needs  tools 
that  he  can  easily  use  to  control  the  progress  of  his  project.  Prooer 
utilization  of  the  RAOX  function,  such  as  shown  here,  helps  the  manager 
identify  the  problems  he  is  interested  in  so  that  he  may  give  them  the 
proper  attention. 
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AMX81-05B 
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Figure  4-3  RADX  Checks  for  Incomplete  Trouble  Reports 


4.2  EVALUATION  OF  DISCREPANCIES 


The  size  and  scope  of  MOM  DFSR,  along  with  its  related  annexes, 
suggest  a  significant  effort  was  originally  involved  in  its  development.  A 
strong  hierarchy  of  traceability  is  communicated  throughout  the  DFSR  and  a 
thorough  discussion  of  not  only  what  processing  was  required  to  be  accomp¬ 
lished,  but  also  how  that  processing  fit  into  the  overall  concept  of  opera¬ 
tions  was  provided.  In  addition,  attempts  were  clearly  made  to  assure 
consistency  in  data  naming  among  the  various  documents  that  compose  the 
DFSR.  In  addition,  we  found  that  the  Decision  Logic  Tables  (DLTs)  used  on 
the  DFSR  were  an  excellent  approach  toward  clearly  defining  the  processing 
required. 

4.2.1  DLT  Considerations 

As  with  all  other  efforts  of  this  size,  human  frailty  intrudes  to  a 
maximum  degree.  We  observed,  for  example,  different  levels  of  quality 
(read  detail)  among  the  DLTs  such  that  we  could  almost  group  them  by 
author.  The  very  fact  that  the  DLTs  provide  considerable  detail  increased 
the  opportunity  for  more  errors  to  occur.  Because  there  probably  were  no 
automated  tools  to  assist  in  the  developer's  verification  of  the  complete¬ 
ness  and  correctness  of  the  DLTs,  the  original  review  and  verification  was 
by  other  humans  with  the  same  set  of  frailties  as  the  DLT  authors. 

One  of  the  difficulties  often  found  in  the  DLTs  was  the  ambiguity 
in  the  description  of  the  processing  step.  For  example: 

Table  319,  Sequence  No.  4  (Figure  4-4)  states:  "Add  MH_EXP_TEN  to 
WORF.  ADJUST  MH_RMN".  This  statement  follows  a  prompt  for,  and  entry  of, 
MH_EXP_TEN  from  Sequence  3  of  Table  316  (not  shown).  Sequence  4  of  Table 
319,  also  follows  other  actions  (Sequences  2  and  3)  that  reauire  data  to  be 
overlayed  on  the  TPR.  .The  Data  element  MH_RMN  is  contained  in  both  the 
WORF  and  the  TPR  files.  The  first  part  of  Sequence  4,  table  319,  is  speci¬ 
fic;  "ADO  MH_EXP_TEN  TO  WORF".  The  second  part  of  seouence  4  ("ADJUST 
MH_RMN“ )  is  ambiguous,  however,  and  the  designer  is  not  sure  if  "ADJUST 
MH  RMN"  refers  to  the  WORF  only,  TPR  only,  or  to  both  files. 
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4.2.2  R  NET  Contribution  to  Identification  of  PLT  Deficiencies 

R  NET  definition  requires  consideration  of  the  availability  of  data 
as  it  flows  through  its  processing  steps  and  provides  strong  clues  for 
identifying  needed  processing  paths  at  nodes  where  branching  decisions  are 
made,  particularly  error  paths  that  could  arise  due  to  the  situation  at 
these  nodes.  This  R_NET  characteristic  was  a  major  factor  in  recognizing 
the  logic  errors  and  omissions  found  in  the  DLTs. 

The  R_NET  definition  step  is  intolerant  of  ambiguity.  In  order  to 
complete  an  R_NET,  all  aspects  of  the  data  flow  in  the  process  must  be 
known.  As  a  result,  several  questions  are  always  under  consideration,  such 
as: 

•  What  GLOBAL  DATA  is  needed? 

•  What  LOCAL  DATA  is  available  from  the  MESSAGE  which 
stimulated  traversal  of  the  R  NET  from  outputs  of 
preceding  processing  steps  (ACPHAs),  or  from  the  initial 
values  of  LOCAL  DATA  which  are  set  each  time  the  R_NET 
is  used? 

•  What  branching  is  appropriate,  what  DATA  will  be  used 
for  branching  decisions,  and  what  DATA  values  will 
determine  which  branch  shall  be  traversed? 

•  What  DATA  is  needed  to  FORM  output  MESSAGES  that  are  to 
be  transmitted  as  a  result  of  R_NET  processing,  what  is 
the  source  of  the  DATA  needed  for  the  transformations 
necessary  to  MAKE  the  needed  output  MESSAGE,  and  what 
processing  steps  (ALPHAS)  are  necessary  to  accomplish 
the  necessary  transformations? 

All  ambiguous  descriptions  have  to  be  directly  addressed  so  that  when 
the  software  engineer  could  not  understand  the  intent  as  described,  or  when 
needed  information  to  complete  the  R_NET  was  missing,  the  problem  quickly 
became  apparent.  Thus,  the  R  NET  development  was  the  major  contributor  in 
the  recognition  of  illogical  processing,  missing  processing,  and  ambiguous 
descriptions  of  processing. 

4.2.3  Special  SREM  Procedures  to  Assure  Unambiguous  DATA  Naming 

One  of  the  most  pervasive  problems  common  to  all  software  specifica¬ 
tions  is  the  difficulty  in  being  specific  about  a  named  DATA  item.  The 
normal  aporoach,  which  was  also  common  in  the  MOM  DFSR,  is  to  try  to  use 
exactly  the  same  name  throughout.  On  the  surface,  this  seems  appropriate 
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but,  in  reality,  that  item  can  actually  be  several  different  data  i tarns 
during  a  process.  Initially  it  may  be  in  the  input  stream  and  be  stored 
for  later  use,  possibly  in  more  than  one  GLOBAL  file.  Later  it  may  be 
accessed  and  placed  in  still  other  GLOBAL  files,  or  used  for  transmission 
in  the  output  stream.  These  may  be  simply  described  as  the  transfer  of  the 
value  resident  from  data  of  one  type  to  another  type.  However,  in  des¬ 
cribing  the  processing  logic  it  is  difficult  to  e<press  the  form  of  the 
data  item  being  described  without  the  use  of  considerable  modifying 
i nformation. 

Take;  for  example,  the  DATA  item  UIC_CUST  (Unit  Identification  Code 
Customer).  On  DLT  4,  the  item  is  used  several  times,  and  is  referred  to  in 
several  forms  as  follows: 

Sequence  No.  Reference  to  UICjCUST 

1,2,3  XMA  UIC_CUST 

1  UICJCUST  ON  X_REF  FILE 

4  UIC_CUST  ON  WORF 

Clearly,  three  different  UIC_CUST  DATA  items  are  involved  here.  The 
writers  of  the  MOM  DFSR  took  pains  to  indicate  which  data  item  was  intend¬ 
ed,  but  at  times  the  meaning  of  the  descriptive  modifiers  was  found  to  be 

ambiguous.  So,  even  though  the  name:  UIC_CUST  will  be  found  in  Annex  A 

and  Annex  B  as  a  data  item  in  input  and  output  descriptions,  and  in  multi¬ 
ple  GLOBAL  files  of  Annex  D,  it  really  is  a  different  data  item  in  each  of 
those  contexts.  As  we  have  seen,  this  is  reflected  by  the  need  to  use 
modifiers  in  the  DLTs  to  indicate  which  UIC_CUST  was  being  described. 

The  way  this  problem  is  handled  within  RSL  on  this  effort  was  to  use 

the  basic  name  ( U I C _ CUST )  and  append  a  descriptive  suffix.  For  example,  if 

UICjCUST  MAKES  an  input  MESSAGE,  we  used  the  name  U TC  CUST  IN.  Conversely, 
if  it  MAKES  an  output  MESSAGE  it  was  given  the  name  UIC  CUST  OUT.  In  its 
GLOBAL  form,  ASSOCIATED  WITH  an  ENTITY _CLASS  or  ENTITYJTYPE,  it  was  g-'ven 

an  appropriate  suffix  for  that  ENTITY.  Some  examples,  showing  the  '■elated 
ENTITV  are: 

•  U I  C_C  iJST C  RF_3 

( CROSS _ REFERENCE _ F I LE ) 

•  UIC_CUST_XMX_DABS 

(CROSS  REFERENCE  TRANSACTIONS  XMX  3  DABS) 
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•  UIC_CUST_XME_A_DABS 

(EQUIPMENT_RECALLJIEV/_ITEM_XME_A_DA8S) 

•  UIC_CUST_EORR 

(EQUIPMENT_RECALL_REO) 

•  UIC_CUST_MPR 

(MAINTENANCE_PROGRAM_REQUIREMENTS) 

•  UIC_CUST_UED 

(USAGE_EXCEPTI0N_LIS7_0ATA_BASE) 

•  UIC_CUST_WORF 

(W0RK_0RDER_REGIS7RATI0N_FILE ) 

By  using  this  approach,  we  have  unambiguously  named  all  the  forms  that  each 
basic  data  item  can  take.  As  a  result,  RADX  can  apply  its  various  tests  to 
each  one  of  these  DA7A  items  and  a  more  precise  determination  of  consis¬ 
tency  will  result. 

4.2.4  Identification  of  Consistency  Problems  via  RSI  and  RADX 

7he  major  contribution  of  RSL  is  the  discovery  of  consistency  orcb- 
lems.  For  example,  RSL  requires  that  every  element  in  the  data  base  pos¬ 
sess  a  unique  name.  7hus,  if  there  is  an  attempt  to  name  a  MESSAGE  with 
the  name  previously  given  to  (say)  a  DA7A  item,  a  translation  error  cede 
will  be  provided  when  an  attemot  is  made  to  enter  the  MESSAGE  into  the  data 
base.  7his  prevents  inadvertent  duplicate  naming  of  different  elements. 

7he  duplication  naming  problem  just  described  Js  most  useful  when 
SREM  is  being  utilized  to  create  the  software  reauirements  from  a  system 
level  reauirement.  Consistency  problems  in  verification  efforts  are  more 
often  discovered  during  the  RADX  evaluation.  But,  in  order  to  use  RADX  to 
discover  these  problems,  a  particular  approach  during  R  MET  development  is 
required  during  the  verification  effort. 

7he  approach  used  for  verifying  the  MOM  DFSR  to  prepare  for  RADX  was 
to  record  the  exact  name  of  the  DATA  item,  as  given  in  the  DLT,  even  if 
known  to  be  wrong,  and  to  use  it  as  described  ‘•'or  r.he  procession,  such  as 
for  branching  decisions,  or  for  ALPHA  IMP’JTS  or  01TPC7S,  or  to  MAKE  an 
output  M£3SAGE.  Part  of  the  RADX  tests  check  DATA  consistency  by  estab¬ 
lishing  the  SET  of  DATA  that  is  produced  by  the  DP  system  (source  DA~A)  and 
a  SET  of  DATA  that  is  used  by  it  (sink  3ATA1  and  then  comoari.no  ‘he  two 
SETs  for  mismatches.  DATA  is  consi^e^ed  to  be  source  DA~A  when  it: 
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•  MAKES  an  input  MESSAGE. 

•  Is  OUTPUT  FROM  an  ALPHA. 


•  Is  LOCAL  but  has  an  INITIALJ/ALUE. 

•  Is  CONTAINED  in  a  FILE  which: 

-  MAKES  an  input  MESSAGE. 

-  Is  OUTPUT  FROM  an  ALPHA. 

Data  is  considered  to  be  sink  DATA  when  it: 

•  MAKES  an  output  MESSAGE. 

•  Is  INPUT  TO  an  ALPHA. 

•  Is  used  (REFERRED)  by  the  R_NET  for  branching  decisions. 

•  Is  RECORDED  BY  a  VALIDATION_POINT. 

•  DELAYS  an  EVENT  on  the  R_NET. 

•  ORDERS  a  FILE  (establishes  a  desired  order  of  DATA 

instances) . 

•  Is  CONTAINED  IN  A  FILE  which: 

-  Makes  an  output  MESSAGE. 

-  Is  INPUT  TO  an  ALPHA. 

-  Is  RECORDED  3Y  a  VALIDATION_POINT . 

All  DATA  that  are  produced  (source  DATA)  should  also  be  used  (sink 
DATA)  and,  conversely,  all  that  are  used  should  be  produce d.  A  porf'on  of 
RADX  is  designed  to  make  that  check.  DATA  may  be  found  via  RADX  that  has 
neither  sink  nor  source.  When  this  occurs,  it  is  DATA  which  has  been  named 
but  never  given  a  relationship  with  any  other  element  such  that  it  ccu'd 
qualify  as  either  sink  or  source  DATA.  DATA  which  has  a  source  but  not  a 
sink,  or  a  sink  without  a  source,  usually  results  from  not  being  consis¬ 
tently  named  in  the  specification  being  verified. 

If  a  mismatch  between  source  and  sink  DATA  occurs,  it  does  not  auto¬ 
matically  follow  that  the  mismatch  is  the  result  of  inconsistent  DA~A 
naming.  It  is  also  possible  that  some  other  problem  may  exist.  Some 
examples : 


•  An  output  MESSAGE  was  FORMED  BY  an  ALPHA  using  DATA 
produced  by  the  ALPHA,  but  the  MESSAGE  was  not  actually 
defined  separately  as  being  MADE  3V  the  DATA  in 
auestion. 

•  An  input  MESSAGE  was  defined  and  the  DATA  that  MAKES  the 
MESSAGE  indicated.  Inadvertently,  that  MESSAGE  was 
never  defined  as  being  FORMED  BY  an  ALPHA  on  an  R_MET. 

•  An  EVENT  was  defined  as  being  DELAYED  BY  a  DATA  item 
(which  actually  is  a  predefined  constant  indicating  the 
length  of  the  delay),  but  the  DATA  item  was  not  qiven  an 
INITIALJ/ALUE. 

Thus,  it  can  be  seen  that  when  there  is  a  mismatch  of  source  and  sink  DATA, 
the  software  engineer  has  to  investigate  the  reason. 

4.2.5  Identification  of  Consistency  Problems  by  Observation 

When  the  approach  given  above  is  used,  inconsistent  DATA  becomes 
imbedded  in  the  data  base.  For  a  normal  verification  effort  this  is  ac¬ 
ceptable,  and  the  inconsistency  is  removed  only  when  the  developer  actually 
corrects  the  inconsistent  name  in  his  specification.  In  our  efforts  under 
this  contract,  however,  we  were  reauired  to  demonstrate  the  REVS  tools  and 
their  use  for  Data  Flow  analysis  and  regeneration  of  the  reaui rements . 

With  imbedded  problems,  neither  of  these  demonstrations  can  be  properly 
accomplished.  Therefore,  only  a  few  inconsistencies  were  allowed  in  the 
data  base  to  illustrate  the  RADX  capabilities  to  discover  them.  For  the 
most  nart,  however,  inconsistencies  recognized  by  the  software  engineers 
during  this  effort  were  recorded  in  Trouble  Reports,  but  corrected  before 
being  entered  into  the  data  base  so  as  to  better  support  the  Data  Flow 
Analysis,  and  to  allow  an  example  of  regenerated  reouirements  to  be  pro¬ 
duced  via  the  RADX  documentation  capability. 

4.2.6  Identification  of  Problems  by  RAQX 

The  primary  role  of  RADX  is  the  determination  of  inconsistency  and 
incompleteness  of  the  information  in  the  data  base.  Nearly  all  the  sets 
are  created  for  those  ourpcses.  The  results  of  the  RADX  runs  which  were 
accomplished  at  the  completion  of  the  data  base,  are  provided  in  Annex  1. 
How  RADX  was  used  was  the  subject  of  earlier  discussions  in  Section  2  and  3 
and,  the re fo>-e ,  will  net  be  repeated  here.  ~he  results  of  ‘he  findings  or 
the  RADX  runs  shewn  in  Aooendix  C  are  summarized  in  Paragraoh  4.4. 
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4.2.7  Summary  of  Deficiency  Findings 

A  total  of  302  Trouble  Reports  have  been  written  as  a  result  of  the 
verification  effort  on  the  MOM  DFSR.  A  percentage  breakout  of  the  kinds  of 
deficiencies  reported  is  shown  in  Figure  4-5. 

The  largest  category  of  deficiencies  was  inconsistency.  This  is  not 

surprising,  given  the  large  number  of  data  names  that  were  involved  and  the 
amount  of  multiple  data  naming  caused  by  the  format  of  the  specification. 
The  process  of  coordinating  the  data  naming  must  have  been  a  large  job 
since  many  people  apparently  worked  to  produce  the  document.  This  factor 
alone  provided  significant  opportunities  for  inconsistent  naming.  The 
benefit  of  the  automated  REVS  tools  is  apparent  when  compared  to  the  manual 
approach  undoubtedly  used  in  the  MOM  DFSR.  Suppose  it  is  discovered  that  a 
data  item  inadvertently  had  been  given  two  names  and  that  an  effort  must  be 
mounted  to  correct  this  inconsistency.  In  the  manual  mode,  many  hundreds 
of  pages  would  have  to  be  inspected  to  assure  that  the  incorrect  name  was 
changed  to  the  one  that  was  to  survive.  It  would  probably  take  an  hour  or 
two  to  check  through  all  the  pages  of  the  DFSR  in  such  an  effort,  plus  the 
time  necessary  to  retype  all  the  affected  pages.  Compare  that  with  how  we 
would  fix  the  problem  with  RSL.  Suppose  the  two  DATA  items  were  in  the 
data  base  named  AAA  and  AAB ,  but  the  correct  name  was  AAA.  We  would  simoly 
enter  the  RSL  command: 

MERGE  AAB  into  AAA. 

As  a  result  of  this  command,  all  the  relationships  and  ail  the  attributes 
of  AAB  would  be  assigned  to  AAA,  and  the  OATA  item  AAB  would  then  be 
purged.  Thus,  if  relationships  and  attributes  equivalent  to  those  used  in 
Annexes  A,  B,  C,  and  D  were  established  by  extension  of  RSL  (as  was  done 
for  the  requirements  regeneration  example),  this  one  command  would  correct 
the  inconsistency  everywhere  it  existed  and  we  could  be  assured  that  if  had 
been.  Hew  long  would  it  take?  Perhaps  15  seconds  at  the  keyboard  and  a 
very  short  computer  run. 

Deficiencies  in  the  categories  "Ambiguous"  and  "Missing"  were  the 
next  most  prevalent  types,  followed  by  "Illogical"  and  " I ncomD1 ete" ,  in 
that  order.  We  have  further  segregated  the  reasons  behind  these  :ategories 
of  deficiencies,  and  they  are  shown  in  Figures  A-6  threugn  A-10,  along  with 
some  limited  Trouble  Report  examples  of  the  Category  of  ^oblen  being 
displayed.  The  length  of  each  bar  on  these  figures  ;s  related  to  the 
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percentage  of  all  the  Trouble  Reports  (left  hand  scale)  in  the  indicated 
CATEGORY_QF_PROBLEM.  The  number  at  the  end  of  each  bar  indicates  the 
actual  Quantity  of  Trouble  Reports  involved.  The  full  listing  of  all 
Trouble  Reports  can  be  found  in  Appendix  D. 


-- 16 


i  i'jiiCL-  '1-10  Components  of  Lhe  CA7LGURY  Of  PROlil  LM:  Incomplete 


4.3  MAJOR  MOM  DFSR  PROBLEMS 

Previous  paragraphs  have  outlined  the  kinds  of  deficiencies  that  have 
been  reported  via  Trouble  Reports.  As  in  all  verification  efforts  we  have 
accomplished  using  SREM,  certain  problems  are  identifiable  as  possessing 
higher  criticality  because  they  represent  situations  which  typically  result 
in  serious  difficulties  for  the  software  designer  in  implementing  the 
intended  processing  described  in  the  reaui rements .  They  may  be  individual 
omissions  or  ambiguities  of  significant  import.  Or  they  may  be  groups  of 
problems  which  individually  are  minor  in  nature,  but  the  Quantity  of  which 
are  significant  enough  to  elevate  the  group  to  the  higher  level  of  criti¬ 
cality  described  in  this  paragraph. 

It  is  important  to  note  that  the  source  of  these  deficiencies  is 
solely  the  Decision  Logic  Tables  (DLTs)  in  Annex  H  of  the  DFSR,  as  sup¬ 
ported  by  Annexes  A,  B,  C  and  0  for  data  definition.  As  described  in  an 
earlier  portion  of  this  report,  we  concluded  that  the  DLTs  were  the  most 
complete  DFSR  description  of  intended  processing,  and  as  a  result,  our 
efforts  were  focused  on  them  for  the  verification  effort.  In  so  doing,  we 
concluded  that  all  appropriate  processing  requirements  should  be  covered  in 
the  DLTs  so  that  the  software  designer  could  expect  to  find  all  the  infor¬ 
mation  he  needed  in  these  tables.  Thus,  he  shouldn't  have  to  search  for 
obscure  footnotes,  or  through  a  large  auantity  of  text,  for  the  key  infor¬ 
mation  he  needs  to  develop  his  design. 

This  approach  may  seem  restrictive  in  the  context  of  this  DFSR 1  s 
since  it  is  rich  in  information,  and  since  significant  effort  has  been 
expended  in  attempting  to  completely  portray  not  only  the  necessary  pro¬ 
cessing,  but  also  the  context  of  the  overall  operations  within  which  the 
processing  requirements  reside.  However,  good  requirements  writing  prac¬ 
tice  suggests  that  fewer  errors  result  when  the  software  designer  f’nds  all 
the  information  he  needs  in  expected,  contextual ly-aopropriate  locations 
within  the  requirements  document.  Consequently,  the  discussion  that 
follows  should  be  read  in  the  light  of  these  comments.  Eaid  another  way, 
some  of  the  deficiencies  outlined  in  following  paragraphs  actually  are 
addressed  in  portions  of  the  DFSR  other  than  the  DL's,  but  our  view  is  that 
the  requirements  details  should  be  consistent  and  comoiete  within  tke  DLTs, 
since  that  is  the  portion  of  the  DFSR  on  which  the  software  designer  is 
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likely  to  rely  for  determining  the  processing  reauirements  his  design  is 
expected  to  satisfy. 

The  areas  of  the  requirements  which  we  feel  could  cause  significant 
problems  for  the  software  designer,  and  which  are  individually  discussed  in 
following  paragraphs,  are  as  follows: 

•  Failure  to  initiate  certain  batch  processing  output 
reports . 

•  Failure  to  use  the  parameter  report  controls. 

•  OASS  production  and  use  inconsistencies. 

•  Work  Order  Number  character  field  confusion. 

•  Lack  of  file  purge  instructions. 

•  Missing  file  contents. 

•  Significant  quantities  of  individually  minor 
deficiencies: 

-  Inconsistent  data  naming. 

Incorrect  QlT  referencing. 

4.3.1  Failure  to  Initiate  Certain  3atch  Processing  Output  Peoorts 

Paragraphs  4.11  and  5.9  indicates  that  the  operator  will  key  for  the 
accomplishment  of  cyclic  (daily,  weekly,  and  monthly!  batch  processing 
efforts  to  produce  periodic  output  reports.  The  DITs  which  produce  these 
reports  are  not  referenced  (called!  by  any  other  DLTs  because  the  initial 
input  (keying  by  the  operator!  is  not  found  in  a  DLT  to  start  the  batch 
processing  that  leads  to  the  output  of  the  periodic  reports,  nc>"  is  an 
input  description  provided  in  Annex  A  to  indicate  that  an  input  message  is 
necessary  to  initiate  this  processing. 

Certain  other  cutout  reports  are  defined  in  DLTs  which  would  be  ex¬ 
pected  to  occur  during  the  chain  of  periodic  preparation  of  output  reports. 
However,  these  reports  would  not  have  been  referenced  ever,  there  had 
been  a  DLT  shewing  the  operator  keying  to  initiate  periodic  report  pro¬ 
cessing.  Whereas  all  the  other  periodic  reports  are  referenced  f-om  one  to 
the  next  (i.e,  initiation  of  a  DL~  series  is  called  *rcm  the  completion  CL~ 
of  a  preceding  series!,  the  initiation  DLTs  of  ‘■free  reports  are  riot 
referenced  from  any  other  DLT. 
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A  third  category  of  output  report  deficiencies  is  those  cases  where 
one  or  more  parts  of  multi -part  outout  reports  are  not  called  for  process¬ 
ing  by  a  DLT,  even  through  the  other  parts  are.  Three  different  output 
reports  fall  into  this  category. 

A  fourth  category  of  problem  exists  in  the  DLTs  where  five  output 
reports  were  not  addressed  by  any  DLT.  That  is,  the  description  of  how 
those  output  reports  were  to  be  developed  and  formatted  was  not  defined  on 
any  DLT.  Table  4.1  lists  the  periodic  output  reports  whose  problems  are 
described  above. 

4.3.2  Failure  to  Use  the  Parameter  Report  Controls 

The  parameter  for  report  control  is  added  to  the  header  segment  of 
several  f i T e s  via  entry  XMZ  (Card  Designator  Code  SAMS:  E),  and  this  input 
is  described  in  DLTs.  However,  these  parameters  are  never  used  in  forming 
the  daily,  weekly,  and  monthly  output  reports,  as  would  be  expected  in 
light  of  the  comments  of  page  A-206  which  describes  the  use  of  these 
parameters . 

4.3.3  DABS  Production  and  Use  Inconsi stencies 

The  Daily  Accumulated  Batch  Storage  (DABS)  is  used  as  a  temporary 
hold  file  for  daily  inputs  entered  into  the  system.  The  information  des¬ 
cribing  the  various  input  formats  to  be  saved  by  DABS  is  found  in  Annex  D 
(Page  D-2C).  The  "Remarks"  block  of  3age  D-2C  lists  the  incut  to  be  saved. 
Five  of  the  inputs  described  in  the  DLTs  as  being  processing  are  not 
indicated  as  required  on  Rage  D-20.  Conversely,  the  DLTs  do  not  show  the 

logic  necessary  to  process  DABS  storage  of  nine  files  that  are  recuired  by 
Annex  D. 

To  comolicate  the  problem,  the  input  descriptions  of  Annex  A  also 
indicate  which  inputs  are  to  be  written  to  DABS.  "These  are  inconsistent 
with  the  similar  information  indicated  in  Annex  D.  To  addition,  rive  or 
the  inputs  shown  in  Annex  A  as  being  stored  in  DABS  are  not  definer  ;n  any 
DL~  as  being  so  stored.  Conversely,  the  DLTs  indicate  storage  to  DABS  of 
five  inputs  "ot  marked  for  storage  in  Annex  a.  "able  4.2  lists  tnese  DATS 
i  nconsi  stone' es  . 
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Table  4.2  Dally  Accumulated  Batch  Storage  (DABS)  Inconsistencies 
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REQUIREMENT 
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4.2.4  Work  Order  Humber  Character  F^eld  Confusion 

After  the  MOM  DFSR  had  been  published,  one  of  several  changes 
involved  the  deletion  of  a  data  element:  P  WON  (Partial  Work  Order 
Number).  It  was  to  be  understood  that  the  data  element:  "Work  Order 
Number"  was  to  supplant  P  WON  wherever  it  appeared  in  the  D17$,  but  the 
actual  changes  to  each  affected  CLT  page  were  not  accomoi i shed. 

Unfortunately ,  this  change  was  not  strai ghtforward .  Because  P_WCN 
had  nine  characters  while  the  Work  Order  Number  had  12,  problems  develooed 
where  subportions  of  PJWON  were  cited  on  DLTs.  The  subporti ons  of  P_W0N 
and  the  Work  Order  Number  (as  to  character  location)  are  not  consistent. 
9ecau$e  of  the  oervasive  use  of  ?  WON  throughout  the  DLTs,  handling  the 
change  in  this  fashion  probably  assures  that  subseauent  designers,  who  may 
not  nave  been  familiar  with  P  WON,  will  be  confused  with  the  DLTs  as  new 
written.  As  much  trouble  as  it  might  be,  there  would  be  a  distinct  benef't 
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in  modifying  all  DLT  references  to  P  WOM  to  those  aopropriate  for  the  Work 
Order  Number. 

4.3.5  Lack  of  File  Purge  Instructions 

The  summary  sheets  for  various  files  in  Annex  D  indicate,  in  one  way 
or  another,  that  the  files  are  to  be  purged.  However,  with  the  exception 
of  the  WGRF  and  TPR,  no  specific  indications  are  provided  in  the  DLTs  to 
describe  under  what  processing  conditions  a  specific  file  is  to  be  purged. 
Failure  to  provide  this  information  may  result  in  unintended  results  if  the 
designer  mi  si nterprets  the  variety  of  notes  in  various  places  concerning 
purging  (none  of  which  precisely  define  the  purge  conditions). 

Thus,  if  the  purge  decision  is  to  be  made  under  software  control, 
this  control  should  be  defined  in  the  DLTs.  If  the  purge  is  under  operator 
control,  an  appropriate  input  message  (or  messages)  should  be  defined  and  a 
OLT  for  each  should  define  how  the  purge  is  to  be  accomplished  and  what 
protective  considerations  are  to  be  included. 

4.3.6  Missing  File  Contents 

The  Shop  Stock  and  Requisitioning  Process  ( Shop/Shipment  Status  ( 4E_, 

AS_  - U _ ,  XMR(B))  Daily  Update  Subprocess  contained  in  DLTs  1601  through 

1630  reauire  the  Supply  Status  File  and  Shipment  Status  File  as  the  basis 
for  Output  Reports  C2-35-4D,  02-34-4Y,  and  also  pa-ts  of  02-99-^R.  These 
two  files  are  not  defined  by  Annex  D  (File  Descriptions'. 

For  the  purpose  of  R-NET  definition,  we  assumed  these  files  were  made 
uo  of  the  data  items  contained  in  Annex  A,  pages  A-66  and  4-71.  However, 
to  assure  that  such  assumptions  do  not  have  to  be  made  by  the  software 
designer,  these  files  should  be  defined  fully  in  Annex  D. 

4.3.7  Significant  Quantities  of  Individually  Minor  Deficiencies 
Two  observed  areas  of  deficiency  are  singled  out  as  important 

problems  by  virtue  of  the  quantity  of  deficiencies  documented.  ~h.ese  are 
1)  Inconsistent  data  naming  and  2)  Incorrect  referencing  of  DLTs. 

Inconsistent  data  naming  is  a  problem  founo  in  virtually  all  software 

requirements  specifications.  In  spite  of  obvious  attempts  to  attain  con¬ 
sistency,  the  sheer  quantity  of  data  items  involved  in  a  system  of  this 
type  just  about  guarantees  the  introduction  of  errors  when  a  manual  system 


4-29 


of  requirements  definition  is  attempted.  This  problem  was  present  in  the 
MOM  OFSR,  particularly  in  the  area  of  batch  processing.  Unless  corrected, 
unintended  introductions  of  spurious  data  may  occur.  As  a  result,  one 
designer  or  coder  may  use  one  data  name,  but  the  different  names  may  be 
inadvertently  used  by  others,  thus  causing  considerable  later  problems  in 
finding  and  correcting  the  problem. 

The  second  pervasive  Droblem  area  is  that  of  DLT  referencing.  We 
believe  the  DLT  approach  is  one  of  the  better  ways  of  describing  intended 
processing  that  we  have  seen.  They  clearly  show  the  kinds  of  decisions 
intended  and  the  order  of  processing  required.  The  problem  we  experienced 
stemmed  from  inaccurate  referencing  from  one  DLT  to  the  next.  Referencing 
was  sometimes  to  the  incorrect  DLT, 'and  sometimes  to  non-existent  DLTs. 
Problems  of  this  kind  often  ari se  when  an  initial  set  of  well  referenced 
DLTs  is  subjected  to  a  change  (insertion  of  new  DL's,  or  deletion  of 
existing  ones),  and  subseauent  consistency  checking  of  referencing  among 
the  new  set  of  DLTs  is  not  completely  accompl i shed.  As  mundane  as  this 
kind  of  error  is,  it  must  be  realized  that  many  more  hcurs  of  software 
designer  efforts  will  be  reauired  to  figure  out  what  was  intended,  than 
will  be  expended  by  the  requirements  engineer  to  modify  the  DL's  to  show 
proper  referencing. 


4.4  FINDINGS  OF  SREM  PHASE  RADX  RUNS 

A  normal  step  in  the  SREM  process  involves  aoplication  of  a  standard 
set  of  static  RADX  checks  to  the  data  base  to  identify  problems  introduced 
during  its  development.  RADX  efforts  under  this  contract  where  constrained 
by  available  Government  furnished  data  processing  time  which  was  limited  to 
4  hours.  In  preparation  for  Regeneration  of  Requirements  we  extended  RSL 
to  contain  appropriate  elements,  attributes,  and  rel ationships  to  duplicate 
several  of  the  annexes  in  the  current  DFSR  directly  from  the  data  base. 
Although  this  approach  is  described  in  more  detail  in  paragraph  4.5,  it  is 
mentioned  here  since  the  larger  data  base  required  more  processing  time 
than  is  normally  experienced  in  a  typical  SREM  application.  As  a  result  of 
the  processing  time  limitation,  it  was  not  possible  to  completely  apply  the 
RADX  tool,  nor  to  completely  regenerate  the  requirements  soeci fication. 
Instead,  we  have  developed  examples  of  these  processes  to  illustrate 
SREM's  capabilities  in  these  areas. 

A  portion  of  the  standard  set  of  RADX  checks  for  Phase  1  and  2  of 
SREM  was  applied  to  the  data  base.  In  addition,  Data  Flow  Analysis  was 
applied  to  a  portion  (one  input  message)  of  the  data  base.  These  results 
are  illustrated  and  discussed  in  Appendix  C. 
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4.5  REGENERATION  OF  REQUIREMENTS 

With  the  completion  of  the  reauirements  data  base,  a  wide  variety  of 
documentation  is  possible.  This  variety  stems  from  the  RSL/REVS 
capability  to: 

•  Control  the  items  to  be  listed  by  the  establishment  of 
SETS  of  HIERARCHIES  of  interest. 

•  Control  the  amount  and  type  of  information  to  be 
displayed  for  each  SET  or  HIERARCHY  of  interest  by  the 
use  of  tne  APPEND  statement. 

•  Define  and  document  any  el  ent  of  interest  with  its 
appropriate  relationship  to  other  elements,  and  with  its 
attriDutes  through  RSL  extension. 

Our  approach  was  to  illustrate  how  portions  of  current  DFSR  documen¬ 
tation  might  be  produced  directly  from  the  data  base.  Although  literal 
copies  of  tables  can  not  be  directly  produced  from  tue  data  base,  all  the 
information  can  be  develooed,  entered  into  the  data  base,  and  these  pro¬ 
duced  in  various  ways  to  represent  the  DFSR  documentation.  Thus,  infor¬ 
mation  was  developed  to  document  the  following  DFSR  documentation: 

•  Annex  A  -  Input  Descriptions 

•  Annex  3  -  Output  Descriptions 

«  Annex  C  -  Data  Element  Descriptions 

•  Annex  D  -  File  Descriptions 

•  Annex  H  -  Decision  Logic  Tables. 

In  addition,  other  documentation  can  be  produced,  such  as  a  totally  cross- 
referenced  listing  of  the  entire  data  bas°. 

This  approach  recresents  a  thorough,  yet  succinct,  description  of  the 
MOM  DFSR  processing  required,  and  of  the  data  elements  involved  in  the 
processing.  The  most  imoortant  aspect  added  through  the  use  of  me  re¬ 
auirements  data  base  to  produce  this  documentation  is  consistent  data 
naming  and  the  retention  of  consistency  when  data  element  names  are 
changed.  For  example,  if  a  data  element  name  must  be  chanced,  a  s'mp1? 
incut  is  made  to  the  data  base  which  guarantees  that  this  data  element  name 
will  be  consistently  changed  every  Diace  the  previous  name  aDpeared  in  any 
of  the  documentation. 
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An  even  bigger  benefit  of  documentation  under  the  SREM  approach  will 
be  realized  when  there  are  changes  to  the  processing  reouirement.  Mo 
matter  whether  the  change  is  an  addition,  an  insert,  a  deletion,  or  a 
change  to  that  described  in  the  data  base,  the  RADX  checks  provide  assur¬ 
ance  that  the  modification  has  not  introduced  unintended  problems  elsewhere 
in  the  requirements.  Or  if  it  has,  the  problems  that  result  are  clearly 
presented  for  corrective  action. 

The  reader  is  invited  to  review  the  documentation  examples  provided 
in  Appendix  B.  There,  each  example  is  described  and  illustrated  to 
demonstrate  the  capability  to  provide  consistent  information  to  document 
the  MOM  DFSR  as  a  result  of  this  SREM  application. 
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5.0  A  SYSTEM..  JGI'iEERING  APPROACH  THE  EVALUATION  OF 


TUI REMEMTS  METHGDCLCGIES 

One  of  the  thorniest  problems  in  requi rements  development  is  eval¬ 
uating  the  impact  of  different  requirements  methodologies  on  the  software 
development  process.  Such  an  evaluation  technique  is  mandatory  for  a 
systematic  comparison,  and  for  selection  of  a  software  requirements  metho¬ 
dology  which  is  most  effectively  applied  to  a  specific  project.  In  this 
section,  we  will  present  a  systems  engineering  approach  to  methodology 
definition  and  evaluation.  This  is  accomplished  by  imbedding  the  require¬ 
ments  generation  in  an  overall  life  cycle  development  context  and  defining 
the  inputs,  outputs,  and  performance  indices  of  the  requirements  metho¬ 
dology.  It  is  motivated  by  the  observation  that  the  purpose  of  a  metho¬ 
dology  is  to  output  a  specified  set  of  information,  such  as  software 
requi rements,  in  a  sequence  of  logical  steps  to  produce  the  final  product; 
in  this  case,  the  tested  software  product. 

Our  discussion  will  compare  the  following  requirements  techniaues  to 

SREM: 

•  The  Jackson  method. 

•  CAOSAT  (or  other  PSl/PSA  versions). 

•  HOS. 

•  5ADT. 

•  I0RL . 

We  will  fi^st  briefly  describe  and  compare  these  techniaues  to  SREM. 
Following  that,  we  will  discuss  the  importance  of  comparing  the  cost  and 
performance  of  such  techniaues  in  the  context  of  the  life  cycle  cost  3nd 
resulting  performance  of  the  software  system.  Finally,  we  will  assess  and 
compare  the  life  cycle  cost  of  each  technique. 


5.1  TECHNICAL  COMPARISON  OF  SREM  TO  OTHER  TECHN IQl'ES 

It  is  impossible  in  a  few  short  pages  to  adequately  describe  the  many 
'•equi rements  and  specification  techniques  and  compare  and  contrast  them 
with  SREM.  In  spite  of  this,  comparison  of  a  few  relevant  techniques  ’s 
worthwhile  to  highlight  some  unique  features  of  SREM.  For  this  purpose,  a 
few  of  the  more  important  techniques,  as  previously  listed,  were  selected 
for  comparison.  The  technical  comparisons  described  below  are  summarized 
in  Table  5.1. 


Table  5.1  A  Comparison  of  Some  Recuirements  Techniques 


All  of  the  ccmDared  techniques  define  orocessing  in  terms  of 
"functions'  with  inputs  and  outputs.  It  is  interesting  to  note  that  ERE''1, 
HOS,  and  ICRl  attempt  to  define  a  stimulus/response  relationship  of  incuts 
to  outputs,  while  Jackson,  PSL/PSA,  and  SADT  express  data  flow  but  not 


1 


precedence  or  control  flow.  All  techniques,  except  SREM,  explicitly  define 
processing  in  terms  of  a  "hierarchy  of  functions",  whereas  SREM  is  based  on 
a  "flat"  graph  model  which  can  be  expressed  in  terms  of  a  hierarchy  of 
subnets  --  a  subtle  but  important  difference. 

Sequences  of  inputs  and  outputs  are  explicitly  defined  by  Jackson's 
technique,  partially  defined  by  SREM,  but  not  defined  by  other  techniques. 
The  comparison  of  SREM  with  Jackson's  technique  is  interesting:  Jackson 
emphasizes  definition  of  a  life  cycle  of  inputs  about  an  object,  and  des¬ 
cribes  the  life  cycle  of  processing  those  seauences,  and  thus  derives  the 
information  (state)  which  must  be  kept  in  the  data  base  about  the  object. 
SREM  requires  the  identification  of  ENTITY_CLASSes  (objects  about  which 
data  is  maintained  in  the  data  processor),  and  the  ENTITY_TYPEs  which 
compose  them  (states  of  the  entity  which  require  maintenance  of  unique  sub¬ 
sets  of  data),  and  the  DATA  which  is  ASSOCIATED  with  the  ENTITY_CLASS  and 

EMTITY_TYPEs .  Input  and  output  messages  are  identified  with  the  ENTITY _ 

TYPE ,  stimulus/response  requirements  are  expressed  in  terms  of  graphs  of 
functions,  and  these  are  then  merged  together  to  form  the  R_NETs.  Thus, 
the  sequences  of  I/O  messages  are  partially  defined  by  the  transitions 
between  EMTITY_TYPEs . 

SREM  explicitly  provides  for  the  expression  and  analysis  of  trace- 
ability  between  a  set  of  ORIGINATING_REOUIREMENTS  and  the  final  processing 
requi rements .  Versions  of  PSL/PSA  have  also  incorporated  this  capability. 
SREM  is  the  only  technique  which  addresses  the  explicit  definition  of 
performance  requirements  (response  times  and  accuracy  of  the  processing 
from  input  to  output).  This  is  done  in  four  steps: 

(1)  Paths  of  processing  are  specified  in  terms  of 
VAL IDATI0N_P0 INTs  on  the  R_NETs. 

(2)  The  paths  are  matched  with  the  CRIGINATING_REQl'IREMENTs 
which  are  applicable. 

(3)  The  ORIGINATING_?.ECUIREMENTs  performance  numbers  are 
decomposed  and  allocated  to  the  paths  of  processing  in 
a  series  of  tradeoff  studies. 

(4)  A  PERFORMANCE_REQU!REMENT  is  defined  which  CONSTRAINS 
the  path,  and  is  given  as  an  attribute  "TEST  which 
inputs  specific  data  from  the  validation  points,  and 
outputs  either  "PASS"  cr  "FAI^1. 
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The  result  is  a  set  of  PERFORMANCE_REQUIREMENTs  with  pre-conditions  and 
decision  points  on  the  R_NET  (input  data  is  valid  but  with  an  out-of-range 
measurement) ,  functional  post-conditions  (specific  data  accessed,  specific 
data  updated,  specific  message  output),  and  performance  post-conditions 
(response  time  and  testable  I/O  accuracy  requirement).  The  R_NET  thus 
provides  the  mechanism  for  graphically  presenting  similarities  and  differ¬ 
ences  of  conditions  for  path  expressions. 

When  we  compare  automated  tools,  we  find  that  SREM  has  an  automated 
language  RSL  with  tools  to  check  static  DATA  consistency,  the  dynamic  DATA 
consistency  processing  of  a  single  MESSAGE,  limited  consistency  checking 
for  sequences  of  MESSAGES  (DATA  is  initialized  when  a  new  ENTITY_TYPE  is 
set)  and  tools  to  support  simulation  generation.  The  language  and  report 
generation  facilities  are  truly  user  extensible,  allowing  a  user  to  add  new 
elements,  attributes,  and  relationships ,  input  instances  of  the  new  ele¬ 
ments  and  relationships,  and  retrieve  them  on  the  same  run. 

Both  Jackson  and  HOS  techniques  are  (at  the  time  of  this  writing) 
currently  manual,  but  tools  are  being  developed.  SADT  has  been  partially 
automated  by  Boeing  Computer  Services  as  AUTOIDEFO.  I ORL  has  automated 
tools  on  a  mi ni-computer  for  defining  f nfomati on  in  a  text-file  and 
diagram  data  base,  and  limited  consistency  analysis  is  available  via 
comparison  of  parameter  tables. 

The  comparison  of  RSL  to  PSL  is  worth  special  attention.  PSL  defines 
processing  requirements  in  terms  of  elements,  attributes,  and  relationships 
by  defining  a  hierarchy  of  functions,  data,  etc.  R  METs  were  defined  as  a 
mechanism  for  defining  sequences  of  processing  requirements  before  RSL  was 
defined.  In  seeking  an  approach  for  defining  a  language  expressing  these 
concepts,  TRW  noted  the  PSL  work  and  decided  to  express  RSL  in  terms  of 
elements,  attributes,  rei ationshi ps ,  and  structures  (R  N£7s,  SUBNETS)  to 
define  the  stimul us/respcnse  conditions.  REVS  was  then  developed  using  the 
FORTRAN  Data  Base  Management  System  used  by  PSA.  in  turn,  later  versions 
of  PSA  incorporated  data  consistency  checking  techniques  first  developed 
for  REVS,  and  techniques  for  automated  simulator  generation  (first  deve¬ 
loped  for  REVS)  are  under  development  for  PSA.  Thus  PSL/PSA  and  RSL/REVS 
have  had  a  substantial  interactive  effect  on  one  another. 

The  combination  of  a  precise  machine  processable  language  with  whicv' 
to  describe  the  software  retirement  consistently  and  unambiguous ly ,  an 
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integrated  consideration  of  structures  which  define  the  logic  of  processing 
in  terms  of  the  data  flow,  the  automated  capability  to  test  consistency, 
completeness  and  traceability  of  the  requirements  data  base,  the  automated 

capability  to  build,  exercise,  and  analyze  a  simulation  of  processing  using  j 

the  actual  requirements  data  base,  all  accomplished  in  precise  ways  estab¬ 
lished  within  the  methodology,  makes  SREM  a  truly  powerful  software  engi¬ 
neering  tool.  Other  competing  software  engineering  tools  have  some  com¬ 
parable  features  to  portions  of  SREM's  integrated  capability.  But  none  of 
them  possess  all  the  features  of  SREM.  TRW  insisted  from  the  start  that 
SREM  be  developed  in  accordance  with  carefully  thought  out,  formal  founda¬ 
tions,  and  that  it  be  capable  of  supporting  the  complete  software  require¬ 
ments  engineering  task. 

Another  reason  why  SREM  excels  is  due  to  its  approach  of  defining 
logic  of  processing  in  an  R  NET  as  a  response  to  each  of  the  input  messages 

that  the  data  processor  may  receive.  The  competing  software  engineering  ^ 

tools  still  maintain  the  functional  hierarchy  as  a  starting  point.  We 

believe  that  if  functions  are  to  be  defined,  they  can  be  more  appropri ately 

defined  after  the  completion  of  the  definition  of  processing  logic  which 

occurs  from  the  stimulus-response  approach.  At  that  time,  appropriate 

partitioning  becomes  more  obvious  and  results  in  less  arbitrarily  defined 

functi ons . 

Two  other  factors  suggested  the  appropri ateness  of  the  stimulus- 
response  approach,  as  the  methodology  was  initially  being  designed.  The 
first  factor  we  observed  was  that,  with  requirements  defined  under  the 
traditional  functional-hierarchy  approach,  the  first  thing  testers  had  to 
do  was  identify  the  various  paths  of  processing  in  the  system  so  that  they 
could  determine  what  software  testing  was  aoDropriate.  We  decided  that  if 
this  was  to  be  done  anyway,  why  not  wr’te  requirements  that  way  to  start 
with?  The  second  factor  we  observed  was  that  prel imi nary  or  process  design 
also  depends  heavily  on  understanding  the  logic  of  Drocessing  flow.  He^e 
again,  it  made  better  sense  to  provide  the  designer  with  the  headstart  that 
the  stimulus-response  approach  provides. 

This  completes  our  look  at  technical  comparisons.  Let  us  next  turn 
to  another  way  to  evaluate  requirements  techniques;  a  look  at  the  life 
cycle  costs  for  using  them  to  develoo  and  maintain  software  reoui remo^ts . 
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5.2  THE  SYSTEM  ENGINEERING  APPROACH  FOR  EVALUATION 

The  starting  point  of  this  discussion  is  presented  in  Figure  5-1, 
which  illustrates  that  the  life  cycle  methodology  will  input  a  problem 
statement  and  all  subsequent  modifications,  and  will  output  a  sequence  of 
versions  of  the  software  documentation  end  product;  the  methodology  ends 
when  the  last  version  is  retired  from  service.  Note  that  the  output  in¬ 
cludes  not  only  the  software  product,  but  all  levels  of  documentation  and 
development  effort  for  the  product.  This  includes  documentation  of  the 
requirements,  their  allocation  to  design  elements,  interface  design,  test 
plan,  and  the  development  plan  (including  cost  and  schedule)  for  component 
development,  integration,  and  test  (including  the  development  of  any  neces¬ 
sary  integration  of  test  tools  and  test  procedures).  The  performance  cri¬ 
teria  appropriate  to  the  overall  methodology  is  the  total  life  cycle  cost 
and  estimates  of  the  performance  of  the  software  system  produced  by  each 
methodology.  Note  that  these  are  separate  indices  so  that  tradeoffs  may 
occur  between  them. 

The  life  cycle  cost  can  be  expressed  in  terms  of  the  costs  of  devel¬ 
oping  each  version,  plus  the  costs  of  operating  each  version.  The  system 
performance  is  a  function  of  the  operating  performance  of  each  version  of 
the  product.  The  cost  of  the  methodology  to  develop  a  revised  version  of 
the  product  is  dependent  on  the  set  of  tools  output  by  the  last  version, 
and  the  lack  of  such  tools  would  increase  the  costs  of  developing  the 
revised  version  substantially. 

The  performance  indices  of  the  activities  to  plan  and  to  coordinate 
design  and  development  can  be  stated  as  the  overall  cost  and  schedule  of 
the  development  effort.  However,  this  does  net  allow  an  assessment  of  the 
true  total  cost  of  requi rements.  That  is,  it  does  not  show  the  downstream 
cost  of  fixing  requirements  errors,  nor  the  costs  of  modifying  the  require¬ 
ments  and  design  in  response  to  changes  in  the  original  '■equ*' rements.  ~o 
get  to  this  level  of  detail,  we  must  decompose  the  methodology  to  highlignc 
these  activities.  \ 

Figure  5-2  highlights  the  activities  of  fixing  errors  and  modifying 
the  requirements  and  design.  The  equations  at  the  bottom  of  Figure  5-2 
present  relationships  between  the  overall  cost  to  develop  the  first  version 
and  the  performance  indices  cf  the  activities  in  this  figure.  A  necessary 
consideration  of  the  activity  to  define  requirements  is  not  only  the  cost 
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of  the  requirements  generation  itself,  but  also  the  number  of  errors  re¬ 
maining  in  those  requirements.  The  total  development  cost  then  includes 
not  only  the  costs  of  planning,  defining  requi rements ,  defining  design,  and 
producing  the  product,  but  must  also  include  the  cost  of  fixing  errors, 
plus  revision  of  the  requirements/design/product  in  response  to  every 
requirements  change. 

The  considerations  presented  to  this  point  have  been  fairly  generic 
in  nature,  in  that  they  could  describe  almost  any  system  or  software  re¬ 
quirements  methodology.  However,  any  further  decomposi tions  will  neces¬ 
sarily  become  methodology  and  tool  specific.  Figure  5-3  presents  an  over¬ 
view  of  how  that  might  occur.  Each  step  of  the  methodology  is  defined  in 
terms  of  specified  inputs  and  outputs,  and  then  decomposed  into  activities 
which  can  be  allocated  between  manual  procedures  for  using  tools,  and  the 
capabilities  required  of  the  tools,  to  support  the  methodology.  The  inter¬ 
face  between  the  procedures  and  the  tools  constitutes  the  requirements  on 
the  man/machine  interface.  That  is,  they  become  the  requirements  on  the 
syntax  for  inputs  to  the  tools  and  for  presenting  the  results  back  to  the 
user. 

The  performance  indices  of  the  requirements  methodology  can  then  be 
decomposed  into  costs  and  schedules  for  each  of  the  steps,  which  in  turn 
are  decomposible  into  costs  for  the  man  and  the  costs  of  the  support  tools. 
Thus,  each  methodology  can  be  described  in  terms  of  the  sequence  of  steps 
of  using  the  tools  to  achieve  a  sequence  of  results,  yielding  different 
estimates  of  costs  and  rates  of  errors  contained  in  the  requi rements .  The 
costs  of  requirements  can  now  be  assessed  in  terms  of  this  model  by  tracing 
the  costs  associated  with  each  of  the  outputs  of  the  requirements  phase 
( see  Fi gure  5-2 ) . 

The  cost  of  requirements  starts  with  the  consideration  of  the  cost  of 
generating  the  initial  requirements  (including  man  and  tool  costs),  but 
that  is  only  part  of  the  total  cost  of  a  methodology.  We  must  be  cognizant 
of  the  following  considerations,  as  well: 
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•  Because  the  costs  of  errors  can  be  ve^y  significant  (as 
we  shall  see  shortly),  it  is  generally  cheaper  to  verify 
requirements  so  as  to  discover  errors  early,  rather  than 
to  find  them  and  fix  them  later.  Since  a  methodology 
may  or  may  not  include  verification,  the  requirements 
generation  costs  should  be  separated  into  two  pieces: 
the  cost  of  requirements  definition,  and  the  cost  of 
requirements  verification. 

•  The  output  of  the  requirements  activity  is  the  require¬ 
ments  used  to  perform  design.  If  the  requirements  con¬ 
tain  errors,  additional  requirements  and  design  work 
will  be  necessary  to  identify  the  errors,  correct  the 
requirements,  and  then  correct  the  design.  In  turn, 
when  the  design  is  complete  and  code  is  being  produced 
and  tested,  additional  code  and  test  costs  may  occur  in 
response  to  correcting  requirements  errors  at  that 
stage.  To  capture  these  effects,  we  will  assign  all 
design  and  development  costs  to  fix  errors  to  the 
requirements  activity;  if  there  were  no  requirements 
errors,  there  would  be  no  such  costs. 

•  As  modifications  to  the  original  problem  statement 
occur,  the  requirements  must  be  revised  to  reflect  these 
changes.  The  costs  of  modifying  the  requirements  can  be 
attributed  to  the  requirements  phase,  but  the  design  and 
production  costs  are  usually  allocated  elsewhere.  Note 
that  as  requirements  are  modified  (even  if  only  1  per¬ 
cent  of  the  requirements  are  changed),  all  of  the  re¬ 
sulting  requirements  must  be  re-verified  to  assure  that 
the  requirements  changes  are  consistent  with  the 
remaining  requi rements .  Note  also  that  the  requirements 
may  be  modified  hundreds  of  times,  and  thus  this  reveri¬ 
fication  cost  can  become  significant  if  not  supported 
with  automated  tools. 

•  Since  the  requirements  are  used  as  the  starting  point  of 
design,  additional  work  may  be  necessary  to  translate 
them  to  a  form  usable  in  the  design  effort.  Assume  for 
the  purpose  of  this  discussion  that,  if  such  trans1  : on 
is  necessary,  the  requirements  activity  should  a«si: 
half  of  the  costs. 

•  Since  the  requirements  must  be  publisned  in  an  accept¬ 
able  form,  the  translation  costs  into  an  acceptable 
documentation  format  must  be  included  as  part  of  the 
requirements  costs. 

•  Since  the  requirements  are  the  starting  point  of  test 
planning,  the  costs  of  translating  them  so  that  test 
case  procedures  can  be  designed  should  also  be  charged 
to  the  requirements  activity. 
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Figure  5-4  presents  a  summary  of  these  costs  and  reflects  that  each  of  the 
above  costs  must  be  paid  for  each  version  of  the  software  system.  This 
includes  the  initial  development  as  well  as  all  the  versions  that  must  be 
developed  during  the  system's  life  cycle. 
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Figure  5-4  Cost  of  Requirements 
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5.3  THE  COST  CF  FIXING  ERRORS  VERSUS  VERIFICATION  COSTS 

The  Equation  of  Figure  5-4  can  be  analyzed  from  a  number  of  view¬ 
points.  First,  consider  that  the  cost  of  fixing  errors  grows  as  a  function 
of  when  the  error  is  discovered  during  the  system's  life  cycle.  Figure 
2-1,  shown  earlier,  presents  an  estimate  of  the  relative  costs  of  fixing 
errors  as  a  function  of  error  discovery  time  derived  from  data  supplied  by 
IBM,  GTE,  and  TRW  projects.  Suppose  we  postulate  that  if  we  performed  only 
99  percent  of  the  requirements  job,  this  would  result  in  errors  which  would 
be  discovered  throughout  the  remainder  of  the  design  and  implementation 
phases  (ignoring  maintenance  for  the  moment).  This  would  require  that  1 
percent  of  the  requirements  job  be  completed  later,  as  well  as  the  effort 
necessary  to  correct  the  design  and  code  and  to  retest  the  system.  If  we 
assume  that  50  percent  of  the  errors  would  be  found  at  Preliminary  Design 
Review  (PDR),  that  50  percent  of  the  remaining  errors  were  found  at  Criti¬ 
cal  Design  Review  (CDR),  that  50  percent  of  the  remaining  errors  were  found 
during  development  test,  and  that  the  remainder  were  found  at  acceptance 
test,  then  the  graph  of  Figure  5-5  results.  Combining  the  results  of  this 
graph  with  the  costs  by  phase  of  Figure  2-1,  we  find  that  if  90  percent  of 
the  requirements  effort  were  successfully  completed  during  the  requirements 
phase,  the  remaining  10  percent  would  still  result  in  a  doubling  of  the 
total  requirements  cost.  If  only  80  percent  of  the  requirements  were 
completed,  then  the  cost  of  the  requirements  would  increase  by  a  factor  of 
five.  If  we  assume  the  requirements  to  cost  20  percent  of  the  project 
budget,  then  the  whole  software  development  project  would  approximately 
double.  Finally,  if  only  50  percent  of  the  requirements  were  completed 
during  the  requirements  phase,  the  total  project  costs  would  approximately 
quadruple  (i.e.,  300  percent  overrun). 

Another  data  point  on  cost  can  be  extracted  from  TRW's  Systems 
Technology  Project  experience.  On  that  Droject,  reouirenents  were  defined 
using  Engagement  Logic,  which  is  a  non-automated  version  of  the  RSL 
functional  requirements.  It  required  flow  charts  which  identified  sequen¬ 
ces  of  processing  steps  for  each  input  message,  showed  decision  points  and 
algorithms,  and  described  inputs  and  outputs  for  each  algorithm.  It  took 
approximate! y  30  man-months  to  oroduce  each  new  version  of  the  Engagement 
Logic,  and  to  check  it  for  consistency.  This  consistency  checking  was 
performed  manually  and  took  approximately  10  to  15  man-months  per  version. 
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Figure  5-5  Example  Analysis 


It  is  interesting  to  note  that  this  level  of  validation  led  to  a  signifi¬ 
cantly  smaller  number  of  errors  at  integration  and  acceptance  test  time, 
because  the  data  flow  had  been  thoroughly  verified  during  the  requi rements 
phase.  It  is  also  interesting  to  note  that  the  same  type  of  data  flow 
analysis  can  be  performed  by  REVS  on  a  CDC  6*100  in  about  10  minutes  of 
processing  time  at  a  cost  of  approximately  S100  for  comDuter  time.  ~r'$ 
shows  the  significant  reduction  in  the  cost  of  attaining  consistency  with 
verification  using  automated  tools. 


5.4  SOFTWARE  REQUIREMENTS  METHODOLOGY  EVALUATION 

The  equation  of  Figure  5-4  can  be  used  to  guide  the  evaluation  of 
different  requirements  methodologies  in  terms  of  comparing  their  respective 
life  cycle  costs.  Table  5.2  provides  an  overview  of  the  relative  costs  of 
four  techniques  to  define  requirements  for  a  large  project  which  we  will 
assume  will  experience  at  least  10  significant  requirements  modifications. 


Table  5.2  Relative  Costs  on  Large  Projects 
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The  methodologies  selected  were  those  of  SREM,  CADSAT  (or  other  versions  of 
PSL/PSA  produced  by  Dr.  Teichroew  at  the  University  of  Michigan),  I0RL 
(produced  by  Teledyne  Brown),  HOS,  SADT,  the  Jackson  Design  Method,  and  a 
standard  state-of-the-art  manual  technique  to  produce  a  MIL  STD  490.  The 
analysis  substantiating  the  estimates  of  cost  are  discussed  below. 

•  Requirements  Generation:  Assume  that  the  cost  of 
denning  requirements  in  an  automated  form  is 
significant.  Then,  since  SREM  requires  definition  of 
more  information  than  CADSAT,  I0RL,  HOS,  or  SADT,  one 
could  argue  that  it  would  be  more  costly  to  use  SREM  to 
define  requi rements ;  and  these  would  be  more  costly  than 
the  purely  manual  Jackson  or  free-fom  technique.  This 
assumption  may  be  incorrect  in  that  it  may  understate 
the  advantages  of  a  structured  methodology  for  focusing 
effort  on  a  specific  sequence  of  steps,  compared  to  the 
degree  of  effort  dissipated  without  such  focus. 
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•  Requirements  Verification:  The  REVS  automated  analyzers 
provide  a  much  more  thorough  analysis  for  a  low  cost 
than  can  be  achieved  by  hand.  CADSAT  has  a  limited 
number  of  analyzers  fe.g.,  can  check  that  all  data  has  a 
legal  source  and  sink,  but  cannot  check  for  correct  data 
flow  because  sequences  of  processing  are  not  represent¬ 
able  in  PSL).  I0RL,  HOS,  and  SADT  similarly  are  weaker 
in  automated  checks.  Thus,  if  the  same  level  of 
consistency  is  to  be  achieved  with  these  tools  as  with 
REVS,  additional  man-hours  must  be  spent.  The  amount  of 
effort  necessary  to  manually  verify  requirements  for  a 
manual  free-form  or  Jackson  techniaue  will  be  even 
higher  than  for  CADSAT  and  I0RL,  because  of  a  total  lack 
of  automated  tools. 

•  Number  of  Errors:  Error  counts  will  be  lowest  with  SREM 
Eiecause  of  the  automated  analyzers;  if  we  assume  that 
the  HOS,  CADSAT  and  IQRL  analyzers  will  remove  specific 
classes  of  errors,  then  these  will  be  lower  than  the 
errors  in  the  manual  specification.  Except  with  SREM, 
the  data  flow  type  of  errors  are  typically  not  found 
until  integration  test  time,  where  they  are  very 
expensive  to  fix. 

•  Requirements  Modifications:  Assume  for  the  moment  that  the 
cost  to  modify  requirements  using  any  automated  technique  is 
about  the  same.  The  cost  of  modifying  a  manual  specification 
will  be  higher  because  of  the  necessity  to  trace  all  impacts 
of  the  change;  the  automated  tools  of  the  other  techniques 
should  assist  the  modification  process.  The  cost  of  SREM  is 
medium,  instead  of  high,  because  of  the  additional 
traceability  techniques  used  during  the  requirements 
generation  activity. 

•  7ranslation  to  Design:  This  is  left  as  an  open  issue 
because  of  the~TacK  of  a  standard  design  technique, 
except  for  tne  Jackson  Technique. 

•  Documentation  Costs:  These  costs  can  vary  from  very  low  to 
medium  •j,'ing  automated  techniques  (depending  on  whether  the 
automat  'Cementation  oroduced  is  in  acceptable  format), 
and  varTt  -rom  lew  to  medium  for  manual  techniques, 
depending  on  desired  format  and  assuming  that  the  analysis 
has  been  performed.  For  axamole,  an  existing  RSL  data 
base  for  a  medium  sized  software  project  has  been 
translated  into  a  standard  3-5  speci fication  in  a  few 
weeks  with  about  3  to  A  people.  This  is  small  in 
comparison  to  the  time  to  generate  such  requirements 
manual  1 y . 

•  Translation  to  Attain  Testable  Reoui rements : 

Since  RSL,  oy  cesTgrT,  produces  testaDle  requi rements , 
the  effort  to  translate  these  into  a  form  for  performing 
test  planning  is  very  low.  I CRL  has,  as  one  of  its 
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character! sties ,  the  statement  of  stimulus/response 
requirements ,  but  does  not  completely  identify  the 
information  to  be  measured,  and  the  accuracy  require¬ 
ments  to  be  met  in  testable  terms,  so  that  additional 
work  is  necessary.  The  great  weakness  of  both  CADSAT, 

SADT  and  a  standard  manual  requirements  technique  is 
that  the  resulting  requirements  are  not  testable,  there¬ 
by  requiring  a  considerable  effort  to  translate  them 
into  a  testable  form.  The  HOS  technique  results  in 
testable  functional  requi rements ,  but  does  not  address 
explicitly  issues  of  accuracy. 

•  Total  cost:  If  we  assume  for  a  medium  to  large  project 
that  several  requirements  modifications  will  take  place, 
then  the  costs  of  requi  rements  generation  and  documenta¬ 
tion  will  be  dominated  by  the  costs  of  performing  veri¬ 
fication  and  the  costs  of  fixing  all  requirements 
errors.  This  leads  to  the  conclusion  that,  since  SRE^ 
identifies  and  reduces  requirements  errors  more 
effectively  than  other  techniques,  the  overall  costs 
will  be  lower  than  those  of  CADSAT,  HOS,  SADT  and  IQRL, 
and  that  these  will  have  lower  overall  costs  than  a 
manual  technique. 

The  conclusions  of  this  analysis  are  a  function  of  project  type, 
project  size,  and  the  design  quality  of  the  software.  If  the  cost  of  an 
error  in  the  software  is  not  large  (i.e.,  can  be  lived  with,  or  fixed  when 
discovered),  then  the  needed  level  of  verification  may  be  lower.  If  the 
size  and  complexity  of  the  software  is  small,  and  there  will  be  no 
significant  modifications  to  the  requirements,  then  an  individual  analyst 
may  be  able  to  perform  verification  in  his  head  as  effectively,  and  with 
little  more  effort  than  with  automated  tools.  However,  for  large  software 
applications,  or  those  requiring  significant  design  quality,  the  use  of 
SREM  becomes  advantageous. 
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5.5  CONCLUSIONS 

At  least  two  interesting  implications  can  be  derived  from  this 
approach  for  defining  overall  the  cost  of  requirements  generation: 

•  Methodology  cost  cannot  be  properly  evaluated  on  the 
basis  of  a  one  time  application  during  the  requirements 
phase.  As  we  have  seen,  a  significant  portion  of  the 
cost  of  a  requirements  methodology  is  a  function  of  when 
the  errors  are  discovered,  and  which  techniques  were 
used  to  correct  them.  A  project  which  has  had  detailed 
reviews  at  PDR,  CDR,  etc.,  will  probably  find  more 
requirements  errors  earlier  than  one  which  does  not.  In 
addition,  the  cost  of  translation  of  requirements  into  a 
form  useful  for  software  design,  test  planning,  and 
project  documentation  is  project  dependent.  Finally, 
the  required  quality  of  software  and  degree  of  risk 
acceptable  to  the  project  of  late  delivery  due  to 
correction  of  errors  detected  during  acceptance  testing 
is  also  project  dependent.  Thus,  without  consideration 
of  these  parameters,  no  true  evaluation  of  the  cost  and 
relative  merit  of  a  software  requirements  methodology  is 
possible. 

•  The  leverage  of  automated  tools  on  the  cost  of  require¬ 
ments  generation  comes  from  a  simple  fact:  even  though 
only  1  percent  of  the  requirements  may  be  modified,  al  1 
of  the  remaining  requirements  must  be  verified,  and  the 
documentation  must  be  modified  correctly  to  reflect  the 
changes.  Thus,  si  nee  modi fi cation ,  verification,  and 
documentation  are  repeated  many  times  on  real  projects, 
tools  which  efficiently  verify  and  document  the  changes 
have  a  higher  payoff.  Finally,  because  the  total  cost 
of  the  requirements  is  lower  with  automated  tools,  it 
may  be  possible  to  use  some  of  the  extra  funding  to 
search  a  wider  design  space  in  order  to  reduce  the 
operational  costs  of  the  software,  or  to  increase  the 
overall  effectiveness  of  the  software  itself. 
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6.0  ASSESSMENT  AND  RECOMMENDATIONS 


In  this  section  we  will  first  consider  the  applicability  of  SREM  to 
Army  management  information  systems.  Next,  we  will  discuss  the  kinds  of 
problems  we  encountered  that  may  be  typical  to  SREM  verification  efforts  on 
management  information  systems.  Finally,  in  light  of  the  problems  found, 
we  will  recommend  enhancements  that  would  increase  SREM's  capability  for 
requirements  formulation  and  requirements  verification. 

6.1  APPLICABILITY  OF  SREM  TO  ARMY  MANAGEMENT  INFORMATION  SYSTEMS 

The  essential  functions  of  a  management  information  computer  system 
are  to  support  the  collection,  correlation,  analysis,  retention,  and  dis¬ 
play  of  information  and  to  support  analysis,  decisions,  dissemination,  and 
other  activities  necessary  to  perform  the  military  mission.  While  the 
range  of  systems  and  the  support  missions  may  be  quite  broad,  most  manage¬ 
ment  information  systems  have  similar  generic  characteri sties  that  dis¬ 
tinguish  them  from  weapon  systems  with  embedded  computers  --  the  type  of 
system  for  which  SREM  was  initially  conceived. 

One  of  the  key  characteri sti cs  of  a  management  information  system  is 
that  it  cannot  be  totally  automated.  There  is  a  man  in  the  loop,  and  he  is 
there  to  accomplish  appropriate  data  entry,  make  situation-dependent  deci¬ 
sions,  apply  judgement,  and  permit  appropriate  responses  to  a  variety  of 
inputs  that  cannot  be  fully  anticipated.  Computer  support  is  provided 
where  fixed  procedural  operations  can  be  defined  and  where  automation  is 
needed  to  eliminate  drudgery,  handle  load  requi rements ,  and/or  net  response 
times.  Since  a  fixed  algorithm  for  performance  of  the  mission  cannot  be 
specified  except,  perhaps,  in  broad  generalities,  the  user  is  given  spe¬ 
cific  automated  capabilities  and  the  ability  to  apply  them  in  seauences  and 
combinations  of  his  choosing  to  perform  his  particular  job.  Heavy  emphasis 
on  human  engineering  and  man/machine  interface  is  necessary  to  make  the 
system  effective  and  responsive. 

The  va-iety  of  different  message  types  entering  and  leaving  the 
system  is  large,  and  formats  may  be  diverse.  Data  base  structures  3re 
typically  large,  varied,  and  complex.  Cross-correl ation  of  data  structures 
is  extensive,  collections  of  data  elements  may  be  used  in  multiple  roles, 
and  data  base  management  may  be  complicated  by  security  requi rements . 
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While  requirements  for  application  software  embedded  in  weapon  sys¬ 
tems  can  be  expressed  in  terms  of  the  engagement  logic  and  operating  rules 
of  the  weapon  system,  it  is  often  difficult  to  specify  requirements  for 
management  information  system  software  in  similar  terms.  First,  the  data 
processor  capabilities  for  management  information  systems  are  often  multi¬ 
purpose  and  their  actual  use  is  determined  by  the  user  within  a  particular 
situation  context.  Second,  the  possible  variety  of  stimuli  to  such  systems 
is  often  so  large  that  comolete  definition  of  all  possible  uses  may  not  be 
possible. 

Even  in  consideration  of  these  differences,  SREM  can  be,  and  has 
been,  applied  to  systems  with  the  characteri sties  of  management  information 
systems.  Examples  of  past  applications  of  SREM  by  TRW  to  such  systems  are 
outl ined  in  Table  6.1  . 

Table  6.1  Description  of  Management  Information  Systems  to  Which 
SREM  Has  Been  Applied 


SYSTEM 

TYPE 

APPLICATION 

DESCRIPTION  OF  SYSTEM  OR  EFFORT 

CV-ASWM 

VERIFICATION 

THIS  SYSTEM  SUPPORTED  THE  COMMAND  AND  CONTROL  OF  ALL 

(U.S.  NAVY ) 

ASPECTS  OF  ASW  FROM  A  CARRIER.  IT  INCLUDED  INFORMATION 

ON  ALL  THREATS;  ALL  AIR,  SURFACE,  AND  SU3-SURFACE 

FRIENCLY  LOCATIONS,  ALL  ASW- SYSTEM  LOCATIONS 

(SUCH  AS  S0N08U0YS );  AND  INFORMATION  ABOUT  ALL  RESOURCES 

THAT  CQULO  BE  BROUGHT  TO  BEAR  ON  THE  ASH  EFFORT 

NAVOAC  BUSiNESS 

DEMONSTRATION 

NAVDAC  IS  THE  NAVAL  DATA  AUTOMAT  ION  COMMAND,  WHICH  nAS 

DATA  PROCESSING 

RESPONSIBILITY  FOR  ALL  "BUSINESS"  DATA  PROCESSING 

(U.S.  NAVY) 

(NON-TACTICAL  SOFTWARE).  SREM  *A$  APPLIED  TO  TWO 

SAMPLE  PROBLEMS  TO  ASSESS  THE  APPLICABILITY  OF  SREM. 

THESE  WERE  THE  SURFACE  WARFARE  DATA  INTERPRETATION 

SYSTEM  (SWARD IS),  A, NO  THE  CONTINGENCY  AMMUNITION 
REQUIREMENTS  AND  SUPPORTABILITY  SYSTEM  (CARESS). 

t  HAWK/  T ~Q-  .■  j 

DEMONSTRATION 

THE  IMPROVED  HAWK  SYSTEM  COMMUNICATES  »ITH  THE  AN,  TSQ-7 S 

,'U.S.  ARMY) 

MISSILE-MINDER  COMMAND  AND  CONTROL  SYSTEM.  THIS  STUDY 
PRODUCED  AN  RSL  DATA  BASE  FOR  THE  I HAWK  SOFTWARE  REQUIRE¬ 
MENTS  INCLUDING  THAT  RESULTING  FROM  INTERFACE  WITH 

AN/TSO-  Is. 
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6.2  SREM  APPLICATION  TO  TYPICAL  MANAGEMENT  INFORMATION  SYSTEMS 

Application  of  SREM  to  these  systems,  as  well  as  to  the  MOM  DFSR, 
presented  certain  unique  application  challenges  that  caused  some  additional 
methodology  concepts  to  be  addressed.  These  will  be  discussed  in  following 
paragraphs. 

6.2.1  CV-ASWM  Application 

One  of  the  most  unique  application  challenges  had  to  do  with  how  to 
define  the  concept  of  a  PPI  scope  filled  with  symbology,  all  of  which  could 
move,  could  be  individually  blinked,  could  be  at  several  levels  of  display 
intensity,  could  be  individually  deleted,  added,  or  temporarily  inhibited, 
and  which  required  various  classes  of  items  (such  as  all  surface  vessels) 
to  be  inhibited.  Until  that  point  in  time,  the  concept  of  SREM  dealt  with 
the  arrival  of  a  single  MESSAGE,  determination  of  appropriate  processing, 
and  the  output  of  resulting  MESSAGES  to  other  subsystems  of  the  weapon 
system,  but  not  to  display  consoles.  Now,  for  the  first  time,  we  had  an 
operator  in  the  loop  and  a  complex  visual  display  to  contend  with. 

Under  old  considerations,  each  change  to  an  object  on  the  screen 
would  have  been  a  new  output  MESSAGE  to  the  CONSOLE.  This  would  have  been 
exceedingly  cumbersome  and  the  resulting  R  NETs  would  have  been  difficult 
to  understand.  Our  solution  was  to  create  a  display  ENTITY_CLASS  that 
contained  all  the  information  about  each  item  on  the  scope,  plus  all  the 
data  required  for  their  display  control.  Thus,  for  each  instance  in  the 
ENTITY_CLASS  there  were  control  DATA  items  to: 

•  Indicate  if  the  symbol  was  blinking. 

•  Describe  the  symbol's  level  of  display  intensity. 

•  Indicate  whether  or  not  the  symbol  was  inhibited. 

In  this  way,  deletion  of  a  displayed  item  could  be  accomplished  by 
having  its  instance  of  the  display  ENTITY_CLA5S  DE3TRCVED  3Y  an  apDropriate 
ALPHA.  Similarly,  new  objects  were  added  to  the  display  ENTITY  CLASS,  when 
appropriate,  by  being  CREATED  3Y  a  different  ALPHA.  Any  change  in  the  con¬ 
trol  data  for  the  display  was  also  indicated  in  this  ENTITY  CLASS  by  chang¬ 
ing  the  value  resident  in  the  apDropriate  Control  DATA  item. 

Thus,  at  any  instant  of  time,  the  appropriate  conditions  of  each  item 
in  the  display  ENTITY  CLASS  were  defined  by  the  value  held  by  the  control 
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OATA  in  each  instance  of  the  display  ENTITY_CLASS.  We  then  defined  the 
display  processing  as  a  self-enabling  R_NET  which  was  initiated  when  the 
system  was  turned  on,  and  which  re-enabled  itself  using  an  EVENT  at  the 
display  refresh  rate.  What  the  R_NET  did  each  time  it  was  enabled  was  to 
access  each  instance  of  the  display  ENTITY_CLASS  which  was  not  inhibited 
(via  a  FOR  EACH  node)  and  used  the  DATA  values  of  that  instance  in  an 
output  MESSAGE  to  the  console. 

A  new  challenge  was  to  describe  the  controls  for  accessing  the  sys¬ 
tem's  data  base,  and  for  allowing  changes  to  be  made  and  examined  at  the 
console  without  actually  changing  the  data  base.  This  was  done  by  estab¬ 
lishing  a  "copy"  of  the  data  base  for  use  (which  meant  temporary  estab¬ 
lishment  of  a  second  ENT  I TY _ C  LASS )  in  the  RSL  data  base  to  represent  the 

copied  one  for  operator  use. 

It  was  also  necessary  to  maintain  information  identifying  the  opera¬ 
ting  mode  of  each  console,  since  certain  functions  were  available  only 
while  the  console  was  in  a  particular  mode.  This  was  accomplished  by 
establishing  an  ENTITY_CLASS  for  console  control  with  the  requisite  control 
DATA.  This  also  required  that  the  first  node  on  each  R_NET  which  was 
ENABLED  BY  the  INPUT_INTERFACE  from  the  consoles  be  checked  to  determine 
the  console's  operating  mode  to  determine  whether  the  MESSAGE  that  had  just 
entered  was  legal  for  that  mode. 

These,  and  other  new  challenges,  had  to  be  met  in  applying  SREM  to 
the  CV-ASWM.  All  of  them  were  overcome  with  a  solution  within  th^  ~apabil- 
ities  and  constraints  of  the  existing  RSL  and  REVS  capabilities. 

6.2.2  NAVDAC  Appl ication 

It  was  concluded  in  the  NAVDAC  study  that: 

''While  some  modification  to  the  REVS  tools  and  SREM  methodology  are 
indicated,  the  approach  developed  originally  for  tactical  oroolems 
appears  to  be  adaptable  to  BDP  (Business  Data  Processing)  needs." 

NAVDAC  Business  Data  Processing  can  be  divided  into  four  major  functional 

categories : 

•  Logistics  -  procurement,  maintenance  and  transportation 
of  military  material,  etc. 

•  Financial  Management  -  accounting,  appropri ation , 
financial  projections,  et_. 
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•  Administration  -  management  information,  executive 
functions  and  decisions,  etc. 

•  Personnel  -  historical  and  current  personnel  data. 

Because  of  the  close  similarity  of  the  NAVDAC  requirement  to  a  man¬ 
agement  information  system,  such  as  the  MOM  DFSR,  we  have  excerpted  the 
portion  of  the  NAVDAC  Final  Report  that  describes  and  evaluates  the  use  of 
SREM  and  the  limitations  experienced.  Systems  to  which  SREM  was  applied 
are  first  described: 

"3.1.1  Surface  Warfare  Data  Interpretation  System  ( SWARD  IS) 

The  SWARDIS  is  the  initial  increment  of  an  ADP  system  that  ultimately 
will  provide  the  staff  of  the  Deputy  Chief  of  Naval  Operations 
(Surface  Warfare)  (Op-03)  with  all  ADP  capabilities  required  to 
support  the  0p-03  functions  and  procedures  involved  in  the 
preparation  of  the  Navy's  Program  Objectives  Memorandum  (POM).  The 
objective  of  the  SWARDIS  is  to  convert  data  from  the  Department  of 
the  Navy  Five  Year  Program  (DNFYP)  files  maintained  by  the  Navy  Cost 
Information  System  (NCIS)  to  a  file  structure  that  conforms  to  the 
0p-03  resource  management  concepts  so  that  the  0p-03  staff  can 
prepare  reports  using  NCIS  Five  Year  Defense  Program  (FYDP)  data 
couched  in  0p-03's  management  terminology.  System  design  concepts 
allow  the  user  staff  to  specify  whatever  data  file  structure  is 
deemed  appropriate,  to  define  the  user  staff  organization  and 
responsibilities  (cognizance)  for  user  programs,  and  to  establish  up 
to  eight  means  of  "priori tizing"  the  resource  requirements  for  which 
the  user  is  responsible." 

"3.1.3  Contingency  Ammunition  Requirements  and  Supportabi 1 i ty  System 
(CARESS)  Model _ 

The  CARESS  model,  developed  for  the  Weapon  Logistics  Readiness 
Division  (J42)  of  CINCLANTFLT,  calculates  the  conventional  ordnance 
needed  to  support  a  contingency  situation  or  a  specific  Operational 
Plan  (CPLAN)  and  determines  whether  or  not  the  Navy  can  meet  the 
needs  on  a  daily  basis.  The  model  determines  and  allocates  task 
force  ammunition  requirements  on  a  day-by-day  basis,  and  then  tests, 
for  each  day,  the  availability  of  the  required  ordnance  and  the 
ability  of  ammunition  ships  assigned  to  the  task  force  to  deliver  the 
ammunition  wnen  it  is  required.  If  a  plan  is  not  supportable,  the 
model  may  indicate  some  of  the  factors  responsible.  If  the  desired 
ordnance  is  not  available,  attempts  are  made  to  substitute  ordnance 
from  compatible  weapon  stocks." 

" .  the  CARESS  REVS  data  base  is  comparati vely  large.  Desoite  its 

size  and  complexity,  we  developed  a  comDrehensi ve  processing 
structure  for  the  problem  within  four  weeks  after  start,  ano  had 
identified  major  critical  issues,  without  previous  exposure  to  the 
application  area." 


3.2  ASSESSMENT  OF  APPLICABILITY 


This  section  presents  TRW's  assessment  of  SREM  applicability  tc  Navy 
BDP  problems,  based  on  evaluation  of  representative  documentation  and 
development  of  the  selected  sample  problems." 

"3.2.1  Project  Si?e  and  Complexity 

Table  6.2  summarizes  the  Navy  BDP  problems  reviewed,  presents  an 
estimate  of  complexity,  and  indicates  the  applicability  of  SREM 
supported  by  the  automated  tools.  The  complexity  of  the  system  was 
estimated  by  TRW  using  factors  defined  by  DoD  Standard  7935.1-S. 

Table  6.2  Survey  of  SREM  Applicability  to  NAVDAC  Applications 
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The  break-point  for  full  SREM  application  would  appear  to  be  a 
complexity  level  of  about  25.  More  complex  projects  would  benefit 
from  full  use  of  the  automated  tools.  Less  complex  projects  would 
benefit  from  manual  utilization  of  the  (SREM)  concepts  down  to  a 
level  of  20  to  21.  Below  this  level,  benefits  would  decrease  to  a 
negligible  value  for  software  reaui rements ,  although  extension 
applications  at  the  system  level  might  be  worthwhile. 

Two  factors  should  qualify  these  estimates.  First,  we  estimated 
complexity  values  without  previous  expedience  in  using  this  standard. 
Experienced  NARDAC  oersonnel  might  derive  nigher  cr  lowed  values  for 
these  projects.  The  break-even  point  should  be  calibrated  accord-no 
to  their  assessment  of  complexity. 

Second,  the  DoD  Standard  complexity  factors  do  not  include  a  direct 
measure  of  the  logical  complexity  of  the  application.  Nor  do  they 
di f ferenti ate  between  the  complexity  of  the  user's  information 
processing  problems  and  the  problems  of  physical  impl ementat' on .  'he 


6-6 


logical  complexity  may  be  inferred  from  the  number  of  people  assigned 
to  the  project  and  its  costs,  but  other  contributing  factors  also 
influence  those  variables,  including  the  overall  size  of  the 
appl i cation . 

Presuming  logical  complexity  roughly  equivalent  to  SWARD  I S  or  CARESS, 
applications  roughly  one-tenth  of  their  size  could  benefit  from  use 
of  SREM.  Indeed,  one  of  the  significant  advantages  of  SREM  is  that 
it  reveals  the  true  size  and  complexity  of  problems,  often 
underestimated  by  purely  verbal  descriptions." 

Certain  RSL  extensions,  which  are  easily  made  because  of  RSL ' s  exten¬ 
sibility  feature  were  found  to  be  required.  Of  more  interest,  however,  are 
the  limitations  that  deserve  REVS  enhancements.  These  include  the 
capabil ity : 

•  For  an  additional  value  for  the  attribute  TYPE  as  it 
applies  to  DATA  to  provide  for  ALPHANUMERIC  DATA.  The 
current  DATA  TYPES  include  INTEGER,  REAL,  BOOLEAN,  and 
ENUMERATION.  REVS  would  need  to  be  changed  to  represent 
this  TYPE  of  DATA  in  simulations,  and  its  use  to  qualify 
an  OR  node  branching  decision  would  have  to  be  worked 
out. 

•  For  complex  ordering  of  an  ENTITYJCLASS ,  ENTITY_TYPE  or 
FILE  on  a  multiple  set  of  keys  (primary,  secondary, 
tertiary,  etc.).  Currently,  one  can  define  the  transi¬ 
tion  from  one  ordering  to  another  only  by  describing  a 
long,  detailed  sequence  of  processing  steps. 

•  For  a  sequential  FOR  EACH  mechanism  to  perform  a  pro¬ 
cessing  step  on  each  instance  of' a  set,  in  a  specified 
set  order. 

t  To  express  WHILE  and  UNTIL  conditions  for  a  FCR  EACH. 

The  current  FOR  EACH  is  intended  to  specify  that  all 
instances  be  processed,  and  if  this  is  to  be  done  only 
until  some  state  is  reached,  it  currently  cannot  be  so 
defined,  structurally. 

•  For  a  SELECT  capability  on  3  MAXIMUM  or  MINIMUM  value  of 
the  DATA  in  some  instance  of  an  ENTITYJCLASS,  ENTITY 
TYPE,  or  FILE.  This  capability  does  not  now  exist,  T>ut 
the  need  for  it  frequently  occurs  in  management  infor¬ 
mation  systems. 

The  above  REVS  changes,  of  course,  would  require  "ETHODCLCGY  mooi f i cati cns , 
as  wel 1 . 
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6.2.3  IHAWK/TSQ73 

This  was  a  large  demonstration  effort  accomplished  in  1977-78  to 
determine  whether  SREM  was  as  applicable  to  tactical  missiles  as  it  was  to 
8MD  systems.  The  conclusion  on  applicablity  of  RSL/'REVS  for  the  study  are 
shown  in  Table  6.3  and,  as  indicated,  certain  RSL  enhancements  were  recog¬ 
nized  as  beneficial.  These  are  briefly  discussed  below. 

Table  6.3  SREM  Applicability  to  the  IHAWK/TSQ73  Application 


•  THE  MAJOR  DIFFERENCES  BETWEEN  I  HAWK  AND  PREVIOUS  BKD  SYSTEM 
CONSTRUCTS,  FROM  THE  STANDPOINT  OF  DIFFERENT  TYPES  OF  SOFTWARE 
REQUIREMENTS,  ARE: 

-  OPERATOR  COMMAND  ORDERS 

-  DISPLAY  PROCESSING 

-  C3  DATA  LINK  PROCESSING  (MESSAGE  SEQUENCING,  DATA  LINK 
CAPACITY,  INTERIM  OUTPUTS) 

-  SUBSYSTEM  SENSING  (CONTINUOUS  INPUT  INTERFACES) 

•  RSL  WAS  ABLE  TO  SPECIFY  ALL  CONDITIONS  IMPOSED  BY  I  HAWK  (WITHOUT 
USE  OF  THE  EXTENSION  SEGMENT) 

•  SOME  CHANGES  TO  THE  LANGUAGE  WERE  IDENTIFIED  THAT  WOULD  PROMOTE 
EASE  OF  EXPRESSION  AND  USER  CONVENIENCE 

-  NON-TERMINAL  OUTPUT  INTERFACES 

-  CHANGES  IN  ENUMERATED  DA TA 

-  STANDARD  FUNCTIONS  IN  CONDITIONALS 

-  ADDITIONAL  RSL  WRITE/'mODIFY  AIDS 


6 . 2 . 3 . 1  Mon-te^minal  Cutout  Interfaces 

The  need  to  specify  the  output  o<"  3  sequence  of  messages  occurred  for 
the  transmission  cf  MESSAGES  over  a  data  link.  An  indirect  approach  had  to 
be  taken  to  express  this  type  of  requirement  in  RSI.  The  information  that 
MAKES  the  MESSAGE  had  to  be  saved  in  rILEs  and  an  R_MET  that  accesses  the 
rILEs  and  determines  the  MESSAGE  to  transmit  had  to  be  developed.  Sh¬ 
allowing  OUTPUT  INTERFACES  to  serve  as  non-terminal  "odes  in  a  structure, 
such  as  shown  in  Figure  6-1,  this  type  of  requirement  woulo  be  easier  to 
specify  and  more  unde  -standaole  in  RSL.  Currently,  an  OUTPUT  INTERFACE 
terminates  a  branch  of  orocessing. 
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Figure  6-1  Illustration  of  Sequential  MESSAGE  Output  Using 
Non-Terminating  OUTPUTJNTERFACEs 

6. 2. 3. 2  Changes  in  Enumerated  DATA 

The  use  of  enumerated  DATA  provides  a  clear  expression  of  the  meaning 
of  DATA  values.  For  example,  it  is  clearer  to  state  that  the  values  for 
SENSORS  are  ''IPAR,  ICWAR,  IHPI"  than  to  state  the  values  as  0,  1,  or  2 . 
There  are  two  changes  pertaining  to  the  use  of  enumerated  DATA  that  would 
make  it  more  useable: 

•  Allow  the  use  of  the  value  of  an  enumerated  DATA  item  in 
the  standard  conditional.  For  example: 

SELECT  ENTITY  CLASS  TRACK  SUCH  THAT  (TRACK  TYPE  = 

REMOTE ) 

WHERE 

DATA  TRACK _TYPE  is  of  TYPE  ENUMERATION  with  a  RANGE 
"LOCAL,  REMOTE". 

Current  -ules  only  allow  either  numerical  values  in  the 
conditional  statement  such  as: 

SELECT  ENTITYJSLASS  TRACK 

SUCH  THAT  (TRACK  NR  =  84) 


6-9 


or  the  comparison  of  two  named  DATA  items  in  the 
conditional  statement,  such  as 

SELECT  ENTITY  CLASS  TRACK 


SUCH  THAT  (TRACK_NR  =  TRACK_NR_IN ) . 

Thus,  an  enumerated  value  (which  is  defined  as  a  value  stated  in  words) 
cannot  currently  be  used  in  a  conditional  statement. 

6. 2. 3. 3  Allow  Standard  Functions  in  Conditional  Statements 
Currently,  the  reference  of  standard  math  functions  in  conditional 

expressions  is  not  allowed  in  RSL.  For  systems  such  as  I  HAWK  (that  perform 
a  lot  of  geometric  computation)  a  capability  to  use  standard  functions  in 
conditional  statements  would  provide  a  more  natural  expression  of  software 
requirements.  Examples  are: 

•  IF  (ABS( RANGE)  >  RMG _ L IM IT ) . 

•  SELECT  TRACK  SUCH  THAT  (SIN(AZ)  >  SECTOR). 

6 . 2 . 3 . 4  Provide  the  Capability  to  Assign  a  Particular  Attribute  and/or 
Relationship  to  a  Collection  of  Elements 

An  example  of  how  this  might  be  useful  is  when  a  set  of  modi fications 
are  to  be  entered  into  the  requirements  data  base  as  the  result  of  a  change 
to  the  software  specification  on  which  the  requirements  data  base  is  based. 
RSL  has  an  attribute  called  VERSION  which  allows  changes  to  be  recognized 
by  adding  this  attribute  to  all  new  data  base  entries  that  are  the  result 
of  such  a  change.  Currently,  each  such  element  has  to  be  stated  as  the 
subject  element  to  which  this  attribute  VERSION  can  then  be  assigned.  What 
is  being  sought  here  is  a  method  of  providing  the  replication  cf  the 
VERSION  attribute  in  a  more  automatic  manner  to  all  effected  elements. 

6 . 2 . 3 . 5  MOM  DFSR  Application 

The  difficulties  we  have  experienced  with  the  ■•’CM  DFSR  have  primarily 
been  those  of  scale,  as  were  described  in  Section  3.0.  *e  also  experienced 
several  of  the  limitations  outlined  above,  plus  two  wnich  were  apparently 
not  encountered  on  other  efforts. 

The  first  enhancement  that  would  have  been  useful  would  be  the  capa¬ 
bility  to  show  the  SELECTion  of  an  instance  of  an  ENTITY  CLASS  or  ENTI_V 
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TYPE  which  possesses  the  DATA  item  that  has  the  next  higher  (or  "lower) 

value  to  that  OATA  item  in  the  currently  SELECTed  instance  of  the  E Si T I T Y _ 

CLASS  or  ENTITY_TYPE.  To  describe  this  requirement  under  current  metho¬ 
dology  is  cumbersome. 

A  second  area  we  encountered,  which  is  unexpressible  within  the 
current  structure  capabil i ties,  was  the  Real-Time  requirement  XMH  starting 
with  DLT  619.  The  essence  of  this  part  of  the  requirement  is  that  when 
CARD_D$G_CO_SAMS  is  input  with  a  value  of  A,  and  INQ_ACT_CD  has  a  numeric 
value,  a  look-up  table  is  accessed  where  a  particular  data  element  name  is 
linked  to  the  INQ_ACT_CD.  The  intent  is  to  use  the  data  name  to  access  its 
equivalent  data  name  in  a  previously  specified  file;  either  the  WCRF  or  the 
TPR.  This  would  require  a  memory  map  showing  the  location  of  the  desired 
data  element  so  that  the  data  element  at  that  location  could  be  accessed 
and  its  value  displayed. 

Conceptually,  access  via  data  location  is  at  a  different  level  than 
that  used  to  describe  normal  application  requirements.  For  example,  in 
RSL,  an  instance  of  an  ENTITY  CLASS  may  be  accessed  such  that  some  DATA 
item  in  the  ENTITYJCLASS  possesses  a  particular  boolean  condition.  This 
may  relate  to  a  comparison  of  the  value  in  the  DATA  item  to  a  real  integer 
number,  or  the  boolean  expression  may  be  true  for  some  comparison  of  values 
of  two  DATA  items.  Both  of  these  conditions  were  illustrated  in  Paragraph 
6. 2. 3. 2  for  the  ENTITY_CLASS:  TRACK.  The  meaning  for  a  statement  of  the 

type  such  as  (TRACK_NR  =  TRACK _ NR _ I N )  is  that  the  vai ue  resident  in  TRACK_ 

MR  is  equal  to  the  value  resident  in  TRACK  MR_IN.  The  portion  of  the  XMH 
requirement  described  above  requires  that  the  eouality  be  accomplished  by 
comparing  the  DATA  name  in  the  look-up  table  to  the  equivalent  name  in  the 
ENTITY  CLASS  of  interest.  Because  this  type  of  comparison  is  not  possible 
within  the  current  SREM  concepts,  it  is  not  possible  to  describe  that 
portion  of  the  XMH  process  on  a  structure.  Fortunately,  tne  designers  of 
SREM  contemplated  that  not  every  software  requirement  which  might  arise 
could  be  defined  on  a  structure.  Thus,  the  element:  UNSTRUCTURED  R  E  CU I  RE  - 
MEMT  was  included  as  an  RSL  element  for  such  an  occurrence.  An  UNS'RLC- 
TURED_REQUIREMEMT  was  used  to  define  this  MCM  DFSR  rorjui '•emc-nt  i"  tK‘- 

requi remen ts  data  base,  'able  6. A  shows  the  limitations  . 

various  SREM  application  as  described  stove. 
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Table  6.4  Enhancements  needed  for  Various  SREM  Applications  to  Systems 

with  Characteristics  Similar  to  Management  Information  Systems 
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6.3  SREM  ENHANCEMENTS 

Table  6.4,  previously  presented,  outlines  certain  of  the  enhancements 
we  would  have  found  useful  in  the  application  of  SREM  to  various  kinds  of 
non-BMD  systems.  We  believe  that  all  of  the  enhancements  are  worth  consi¬ 
dering-  with  the  exceotion  of  Item  9.  The  concept  of  application  of  SREM  to 
the  level  requiring  manipulation  of  data  based  on  memory  locations  is  at  a 
level  of  detail  not  contemplated  for  SREM.  Further,  requirements  of  this 
kind  can  be  stated  textually  much  more  easily  and  clearly. 

The  other  nine  enhancements  would  be  useful  to  ease  application 
efforts,  and  to  produce  clearer  understanding  for  the  software  designer, 
than  is  the  case  using  current  concepts.  Based  on  our  efforts  to  date, 
however,  we  believe  we  can  work  around  these  limitations  satisfactorily, 
even  if  enhancements  were  not  pursued.  Although  it  would  be  necessary  to 
investigate  the  scope  of  these  enhancements  to  determine  their  impact  on 
REVS  translation,  RADX,  and  simulation  functions,  it  is  fair  to  say  that 
they  probably  are  not  trivial. 

One  additional  capability  would  have  great  utility  in  the  software 
requirements  development  process;  the  capability  to  automatically  produce 
the  software  requirements  document  in  an  appropriate  format  from  the  RSL 
data  base.  Currently,  various  RADX  conmands  can  be  used  to  present  ele¬ 
ments  of  the  data  base  in  various  ways.  The  sample  regeneration  of  re¬ 
quirements  for  a  portion  of  the  MOM  DFSR  in  Appendix  B  is  an  example  of  the 
current  capability.  Although  RADX  provides  a  lot  of  flexibility  it  cannot 
produce  a  specification  in  a  current  Army  format.  It  would  be  feasible, 
however,  to  add  this  capability.  Of  all  the  possible  improvements 
discussed,  a  "specification  generator"  of  this  type  is  probably  the  most 
important  and  would  add  a  truly  useful  capability  for  Army  SREM  users. 
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6.4  A  COMPLEMENTARY  TOOL  FOR  SREM 


As  we  have  discussed,  SREM  is  a  methodology  which  provides  the  ap¬ 
proach,  the  language,  and  the  automated  tools  to  1)  define  the  software 
requirements  from  the  system  level  requi rements ,  or  2)  verify  the  adequacy 
of  an  existing  software  requirement.  If  it  is  the  Army's  intention  to 
utilize  the  full  power  of  SREM  by  applying  it  to  def i ne  software  require¬ 
ments  (as  opposed  to  only  its  verification  role)  then  TRW's  Performance  and 
Cost  Analysis  Model  (PERCAM)  is  a  logical  complementary  tool  at  the  system 
level . 

PERCAM' s  primary  role  is  the  investigation  of  overall  operating 
considerations  for  computer  systems,  to  identifying  bottlenecks  caused  by 
resource  constraints,  and  to  provide  a  quick-response  tool  for  evaluating 
the  capabilities  and  costs  of  different  arrangements  or  types  of  processing 
equipment  to  accomplish  an  overall  requirement.  Investigation  miqht  con¬ 
sider  processing  loads  over  time,  and  the  adequacy  of  throughput,  queue 
loading,  memory  capacity,  communication  data  rates,  etc.,  to  handle  these 
loads. 

Using  results  of  these  simulations,  PERCAM  would  present  a  comparison 
of  the  alternative  processing  arrangements ,  computer  hardware  candidates, 
and  the  resulting  costs  of  the  approaches  under  consideration.  It  could 
suggest  the  best  arrangement  of  core  versus  off-line  memory,  the  number  and 
location  of  operators  needed,  and  where  critical,  the  speed  of  response  to 
operating  loads.  Its  relationship  to  SREM  is  through  the  identification 
ORIGINATING_REQUIREMENT  that  must  be  imposed  on  the  software  for  the 
desired  system. 

PERCAM  also  is  useful  in  assessing  operational  changes  under  consid¬ 
eration  which  would  impact  processing  on  an  existing  system.  It  provides 
suggestions  for  alternative  computer  and/or  communication  resources  to 
handle  the  changed  processing  loads  or  throughput  requi rements ,  or  the  best 
reallocation  of  existing  resources  to  support  the  changes. 

Of  course,  there  are  many  ways  of  solving  problems  of  this  type.  The 
purpose  of  the  remainder  of  this  discussion  is  to  describe  PERCAM  and  to 
highlight  its  rapid  turn-around  capability,  its  low  cost  of  appl i cati o" , 
and  the  simplicity  of  its  use,  when  compared  to  other  tools  which  exist  for 
analysis  of  this  type. 
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Analysis  tools  for  use  in  conducting  tradeoff  studies  and  in  evaluat¬ 
ing  system  elements,  complete  systems  and  system  families  in  a  dynamic 
simulation  are  categorized  in  two  general  types.  The  first  type  comprises 
simple,  easy-to-use  models  (usually  based  on  linear  programing,  game 
theory,  etc.)  that  accommodate  only  gross  system  descriptions  and  cannot 
directly  measure  the  effect  of  variations  in  system  components,  organiza¬ 
tional  structure,  or  scenario.  The  second  type  is  characterized  by  complex 
and  detailed  time-dependent,  high-fidelity  system  simulations  which  are 
inflexible,  require  large  and  detailed  data  bases,  a  high  degree  of  user 
skill,  and  which  provide  highly  detailed  re-sults. 

The  research  and  development  planning  process  usually  calls  for  the 
rapid  evaluation  of  candidate  systems  and  system  components  under  condi¬ 
tions  which  represent  current  or  projected  system  capabilities  and  scena¬ 
rios.  The  necessity  to  quickly  eval uate  .the  effects  of  variations  in 
component  performance,  cost,  and  system  configuration  preclude,  in  many 
cases,  the  use  of  the  simpler  models  during  this  stage.  While  it  is  pos¬ 
sible  to  use  a  large-scale  conventional  simulation  to  tradeoff  studies 
involving  changes  in  system  configuration  and  in  system  component  charac¬ 
teristics,  the  required  setup  time  and  the  computer  and  manpower  resources 
is  frequently  much  larger  than  the  plan  development  task  could  support. 

An  analysis  tool  to  assess  these  early  requirements  should  provide 
quick  turn-around  analyses,  be  easily  adaptable  to  a  variety  of  problems 
and  to  a  variety  of  requirements  fidelities,  incorporate  the  ability  to 
represent  and  to  vary  scenarios  and  operational  doctrines,  permit  the 
presentation  of  interaction  of  the  proposed  system  with  its  operational 
environment,  and  incorporate  the  model  which  permits  comparative  effective¬ 
ness  evaluation  of  dissimilar  systems.  The  TRW  systems  analysis  tool, 
PERCAM,  has  been  developed  to  meet  these  requirements. 

PERCAM  is  a  simulation  methodology  which  provides  a  set  of  software 
tools  to  automate  simulation  generation  directly  from  Event  Logic  Trees 
(ELTs)  —  a  graphic  model  of  system  logic  and  control.  The  key  elements  of 
PERCAM  simulation  methodology  are:  the  ELTs  modeling  technique,  the  PERCAM 
preprocessor  and  underlying  simulation  superstructure .  Systems  architec¬ 
ture  and  software  modeling  is  accomplished  with  the  preprocessor  which  uses 
a  library  of  FORTRAN  components  similar  to  macros  to  construct  simulation 
models  according  to  user  inputs.  The  structure  of  the  simulation  is 
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modular,  flexible,  and  specifically  designed  to  provide  high  visibility  to 
system  engineers  and  designers.  Changes  to  system  parameters,  individual 
system  models,  or  system  configuration  are  easily  accomplished.  PERCAM  is 
operable  on  the  COC  and  VAX  11/780  computer  systems. 

Event  Logic  Trees  (ELTs),  illustrated  in  Figure  6-2,  are  structured 
graphical  representations  of  the  sequence  of  actions  performed  by  a  system 
in  its  operating  environment.  The  ELT  consists  of  a  series  of  linked 
functional  blocks  which  describe  the  operational  paths  the  system  may  take 
to  reach  any  number  of  termination  points.  Branching  within  the  tree  is 
controlled  by  various  decision  nodes. 

The  transformation  step  from  the  ELT  description  to  the  PERCAM  input 
description  is  straight-forward  and,  in  fact,  can  be  considered  as  a  "cook¬ 
book"  approach.  Since  the  ELT  is  constructed  with  specific  components  in 
mind,  each  point  on  the  ELT  corresponds  to  a  particular  component  and  thus, 
the  specific  data  for  that  component  will  be  defined  by  the  user  when  the 
ELT  is  transformed  into  a  computer  processable  input  description. 

PERCAM  provides  a  quick  response,  low  cost  capability  for  exposing 
system  operational  issues  via  system  simulation.  The  PERCAM  methodology 
facilitates  quick  assessment  of  degraded  nodes  of  system  operation,  makes 
possible  the  determination  of  the  key  operational  characteristics  of  alter¬ 
nate  system  configurations ,  provides  a  bulk-filter  to  determine  critical 
issues  and  high  impact  design  tradeoffs,  and  at  the  same  time  provides 
insight  into  peak  loading  effects  and  throughput  bottlenecks. 

Flexibility  and  long-term  growth  potential  are  an  inherent  feature  of 
the  PERCAM  concept.  Since  the  component  library  can  easily  be  updated  and 
modified,  component  availability  can  be  upgraded  to  keep  pace  with 
evolutional  developments.  New  PERCAM  components  can  be  added  to  represent 
new  and  innovative  logic  concepts  or  to  simply  chain  together  a  set  of 
often  utilized  macros. 

Growth  potential  for  PERCAM  based  simulation  is  significantly 
enhanced  due  to  the  high  level  sel f-documenti ng  communication  qualities  of 
ELT  descriptions.  Systems  Analysts  are  freed  from  the  fears  and  complexity 
of  large,  slowly  evolving  customized  simulation  codes  whose  developers  are 
no  longer  available. 
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6.5  SUMMARY 


The  major  observation  derived  from  the  SREM  application  to  the  MOM 
DFSR  was  that  the  current  definition  of  RSL  and  REVS  was  adequate  in  scope 
and  flexibility  to  verify  all  stated  requi rements .  Some  extensions  of  the 
language  were  found  appropriate  to  meet  certain  management  support  func¬ 
tions  (such  as  those  related  to  Trouble  Reports),  and  to  provide  certain 
RADX  documentation  to  produce  information  similar  to  that  presented  in 
Annexes  A,  8,  C,  and  0.  This  latter  extension  was  primarily  for  the 
purpose  of  illustrating  that  RSL  extension  can  provide  the  flexibility  to 
produce  information,  such  as  DATA  names,  in  various  contexts,  each  with 
their  own  particular  relationships  and  attributes.  Even  though  exact 
formats  cannot  currently  be  produced  directly  by  RADX  commands,  all  the 
relevent  information  can  be  provided,  as  illustrated  in  Appendix  3. 

As  has  been  experienced  on  previous  SREM  applications,  we  found  that 
RSL  forces  a  level  of  completeness  and  specificity  that  is  more  technically 
consistent  than  can  be  obtained  with  traditional  English  speci fications , 
and  it  places  more  formality  and  discipline  into  the  requirements  develop¬ 
ment  activity  than  is  possible  with  a  manual  approach.  This  was  reflected 
in  this  verification  effort  by  the  high  quantity  of  deficiencies  found  in 
the  MCMs  DFSR.  The  added  effort  initially  required  with  SREM  will  be  more 
than  returned  during  the  software  design,  implementation,  and  test  phases, 
and  thus  reduce  the  cotal  cost  of  the  software  acquisition.  There  is  also 
a  body  of  opinion  that  the  cost  of  the  requirements  development  itself  may 
actually  be  less  expensive  when  SREM  is  applied  for  software  requirements 
develooment.  this  is  because  the  rapid,  consistent  printouts  reduce  the 
need  for  coordination  and  manual  consistency  checking,  and  the  methodology 
itself  efficiently  focuses  the  necessary  activities. 

REVS  contains  a  variety  of  user  functions  that  are  available  for  the 
specification,  analysis,  simulation,  and  documentation  of  software  require¬ 
ments.  All  of  these  functions,  except  the  simulation  function  (which  was 
not  required  under  this  contract)  were  exercised  during  the  REVS  applica¬ 
tion  to  the  MCM  DFSR.  Since  the  majority  of  the  options  of  each  function 
were  necessary  to  oevelop  and  state  the  MCM  DFSR  requi rements ,  this  effort 
provided  a  detailed  test.  As  in  previous  efforts,  it  was  found  that  cer¬ 
tain  enhancements  would  have  assisted  in  assuring  that  the  SREM  application 


was  not  only  more  efficient,  but  also  more  understandable  for  the  software 
designer's  use. 

The  importance  of  utilizing  an  organized  approach  (a  methodology) 
with  the  supporting  automated  capability  to  check  the  consistency,  com¬ 
pleteness,  clarity,  logicalness,  testability,  and  traceability  cannot  be 
over-estimated.  The  need  to  attain  good  software  requirements  prior  to 
software  design  and  coding  is  understood  by  nearly  all  involved  in  data 
processing.  However,  it  is  only  recently  that  sufficient  interest  has  been 
demonstrated  to  cause  a  variety  of  software  engineering  tools  to  be 
developed  and  offered  to  the  community  for  use.  Based  on  the  assessment  of 
requirements  techniques  provided  in  Section  5,  we  believe  that  SREM  has  the 
best  overall  combination  of  capabilities  to  assure  a  positive  impact  in 
reducing  the  cost  and  risk  of  software  development. 
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6.6  RECOMMENDATIONS 


If  the  decision  is  made  to  implement  SREM  as  a  software  tool  within 
the  Army,  we  recommend  the  following: 

•  Consider  implementation  of  the  RSL/REVS  enhancements 
along  the  lines  mentioned  above. 

•  Develop  a  strategy  for  implementation  of  SREM  for 
software  requirements  development  and  verification  (or 
both)  including  the  necessary  means  to  enforce  its 
appl ication. 

•  Establish  a  plan  for  introduction  of  the  methodology  for 
both  practitioners  and  managers,  and  for  periodic  SREM 
application  training. 

•  Develop  the  capability  to  automatically  produce  software 
requirements  in  accordance  with  appropriate  Army  speci¬ 
fication  formats  via  RADX  from  a  requirements  data  base 
built  as  the  result  of  a  SREM  application,  using 
"specification  generators"  capability,  as  described 
earl ier . 

In  any  of  the  efforts  described  above,  the  Army  should  coordinate  its  SREM- 
related  efforts  with  BMDATC  and  with  the  U.  S.  Air  Force  at  Rome  Air 
Development  Center  (RADC).  Both  of  these  agencies  are  involved  in  efforts 
of  related  interest. 

BMDATC  continues  to  investigate  advanced  technology  in  the  software 
area.  This  includes  considerations  of  Distributed  Data  Processing  (DDP), 
the  development  of  System  Software  Requirements  Engineering  Methodology 
(SSREM)  for  producing  the  system  level  software  requirement  from  the  top 
level  system  specification  and  the  development  of  a  Software  Design 
Engineering  Methodology  (SDEM)  for  software  design.  These  last  two  will  be 
SREM-like  approaches  with  a  methodology,  a  specific  language,  and  a  set  of 
automated  tools  to  support  the  effort.  3oth  will  be  integrated  with  SREM 
so  that  the  system  level  software  reauirements  data  base  created  by  the 
SSREM  will  be  directly  useable  for  SREM  application  in  developing  the 
software  requirements  specification.  Similarly,  the  data  base  deveiooed 
during  the  application  of  SREM  will  feed  directly  into  the  SDEM  effort. 

When  completed,  an  integrated,  consistent  method  for  accomplishing  all  the 
engineering  effort  necessary  to  transit  from  tne  System  Soeci fication  to 
the  point  of  coding  the  software  design  is  intended.  Consequently,  efforts 
in  these  areas  should  be  of  continuing  interest  during  their  development. 
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RADC  has  apparently  decided  to  use  SREM  as  a  standard  tool  for  the 
3 

development  of  C  I  systems  within  the  U.  S.  Air  Force.  They  have  recently 

issued  an  RFP,  the  objective  of  which  is  "to  develop  the  methodology, 

tools,  and  documentation  required  for  a  software  requirements  specification 

and  analysis  capability  which  can  generate  and  validate  a  formal  equivalent 

of  the  Computer  Development  Specification  (MIL-STD  490  type  B5)  as  used  in 

3 

the  acquisition  of  computer  systems  embedded  within  Air  Force  C  I  systems". 
This  effort  will  provide  for  the  study  and  development  of  enhancements  to 
overcome  some  of  the  limitations  described  earlier  in  this  section.  It 
also  will  provide  for  improvements  to  the  methodology,  to  REVS  software, 
for  updating  the  existing  SREM  documentation,  and  for  improving  the  educa¬ 
tional  materials  to  incorporate  the  enhancements  produced  under  the  con¬ 
tract.  Clearly,  a  harmonization  of  AIRMICS  efforts  with  those  of  the  Air 
Force  and  with  BMDATC  makes  good  economic  sense  for  all  concerned. 
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